-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sql: error when executing INSERT: ERROR: got 7 values but expected 6 #98602
Labels
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
O-qa
T-sql-queries
SQL Queries Team
Comments
rytaft
added
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
O-qa
labels
Mar 14, 2023
craig bot
pushed a commit
that referenced
this issue
Apr 6, 2023
100598: upgrade/upgrades: fix TestUpgradeSchemaChangerElements race condition r=fqazi a=fqazi Previously, TestUpgradeSchemaChangerElements started a schema change and intentionally caused it to be paused. It then resumed this job and started a version upgrade. The version upgrade being tested is meant to pause schema change jobs intentionally, which could lead to the job getting paused again before it resumed. This patch, adds one more channel to ensure synchronization in this sequence. Additionally, we will further limit the scope of version to make this test a bit shorter, so that we are only focused on the upgrade for schema changes Fixes: #98602 Release note: None 100675: importer: fix flaky TestImportIntoCSV r=yuzefovich a=yuzefovich This commit fixes an oversight of 117f712 that made TestImportIntoCSV flaky. In particular, that commit made it so that if the import fails but is actually paused, the corresponding import job is resumed. This is needed in order to bring the table back online before it can be safely dropped. However, resuming of the job might fail if the job still has the "pause-requested" status, thus, this commit adds a waiting mechanism before the job transitions out of this status. Additionally, that resume can hang (or take a very long time), so this commit switches to canceling the job instead. Fixes: #100366. Fixes: #100477. Release note: None 100761: flowinfra: fix a rare bug that could make drain be stuck forever r=yuzefovich a=yuzefovich This commit fixes a long-standing bug around the flow registry that could make the drain loop be stuck forever. Drain process works by draining several components in a loop until each component reports that there was no more remaining work when the drain iteration was initiated. One of the components to be drained is the flow registry: namely, we want to make sure that there are no more remote flows present on the node. We track that by having a map from the `FlowID` to the `flowEntry` object. Previously, it was possible for a `flowEntry` to become "stale" and remain in the map forever. In particular, this was the case when - `ConnectInboundStream` was called before the flow was scheduled - the gRPC "handshake" failed in `ConnectInboundStream` (most likely due to a network fluke) - the flow never arrived (perhaps it was canceled before `Flow.StartInternal` is called), or it arrived too late when the registry was marked as "draining". With such a scenario we would create a `flowEntry` with ref count of zero and add it to the map in `ConnectInboundStream`, but no one would ever remove it. This commit fixes this oversight by adjusting the ref counting logic a bit so that we always hold a reference throughout (and only until the end of) `ConnectInboundStream`. Fixes: #100710. Release note (bug fix): A rare bug with distributed plans shutdown has been fixed that previously could make the graceful drain of cockroach nodes be retrying forever. The bug has been present since before 22.1. The drain process is affected by this bug if you see messages in the logs like `drain details: distSQL execution flows:` with non-zero number of flows that isn't going down over long period of time. 100768: build: append `-dirty` suffix if relevant r=rail a=rickystewart This command and the `rev-parse HEAD` command behave identically except if the workspace is dirty, this command adds a `-dirty` suffix. Epic: none Release note: None Co-authored-by: Faizan Qazi <[email protected]> Co-authored-by: Yahor Yuzefovich <[email protected]> Co-authored-by: Ricky Stewart <[email protected]>
This issue is not fixed. I think it was closed by accident. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
O-qa
T-sql-queries
SQL Queries Team
Describe the problem
On master, I'm getting an error when I try to perform an insert: "ERROR: got 7 values but expected 6". This query succeeds in Postgres.
To Reproduce
On a single-node local cluster, run:
The last command fails with "ERROR: got 7 values but expected 6". This should not happen.
Expected behavior
There should be no error. As a workaround, I can successfully run:
(Note I've just put the original query into a subquery.)
Environment:
Jira issue: CRDB-25354
The text was updated successfully, but these errors were encountered: