-
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
'AS OF SYSTEM TIME' Can Read Incompatible Data #106764
Labels
A-cluster-upgrades
A-sql-execution
Relating to SQL execution.
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
Comments
jeffswenson
added
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
A-sql-execution
Relating to SQL execution.
A-cluster-upgrades
labels
Jul 13, 2023
adityamaru
added a commit
to adityamaru/cockroach
that referenced
this issue
Jul 25, 2023
In cockroachdb#106762 we noticed that if a query is executed with an AS OF SYSTEM TIME clause that picks a transaction timestamp before the job_type migration, then parts of the jobs infrastructure will attempt to query the job_type column even though it doesn't exist at the transaction's timestamp. As a short term fix, when we encounter an `UndefinedColumn` error for the `job_type` column in `crdb_internal.jobs` we generate a synthetic retryable error so that the txn is pushed to a higher timestamp at which the upgrade will have completed and the `job_type` column will be visible. The longer term fix is being tracked in cockroachdb#106764. We are intentionally approaching this issue with a whack-a-mole approach to stabilize the tests the are running into this issue. We think time is better spent designing and investing in the longer term solution that will be tracked in cockroachdb#106764. Fixes: cockroachdb#107169 Informs: cockroachdb#106762 Release note: None
craig bot
pushed a commit
that referenced
this issue
Jul 26, 2023
107570: sql,jobs: short-term fix for `UndefinedColumn` job_type error r=HonoreDB a=adityamaru In #106762 we noticed that if a query is executed with an AS OF SYSTEM TIME clause that picks a transaction timestamp before the job_type migration, then parts of the jobs infrastructure will attempt to query the job_type column even though it doesn't exist at the transaction's timestamp. As a short term fix, when we encounter an `UndefinedColumn` error for the `job_type` column in `crdb_internal.jobs` we generate a synthetic retryable error so that the txn is pushed to a higher timestamp at which the upgrade will have completed and the `job_type` column will be visible. The longer term fix is being tracked in #106764. We are intentionally approaching this issue with a whack-a-mole approach to stabilize the tests the are running into this issue. We think time is better spent designing and investing in the longer term solution that will be tracked in #106764. Fixes: #107169 Informs: #106762 Release note: None 107641: sql: disallow aggregate functions in ORDER BY in DELETE and UPDATE r=mgartner a=mgartner This commit disallows aggregate functions in the context of an `ORDER BY` clause in a `DELETE` or `UPDATE` statement. An aggregate function in an `ORDER BY` would require a `GROUP BY` clause to group non-aggregate columns. A `GROUP BY` is not allowed in `DELETE` or `UPDATE` statements as it's not obvious how grouping in these statements would behave. So we simply disallow aggregates in `ORDER BY` instead. Fixes #107634 Release note (bug fix): A bug has been fixed that caused internal errors when using an aggregate function in an `ORDER BY` clause of a `DELETE` or `UPDATE` statement. Aggregate functions are no longer allowed in these contexts. The bug has been present since at least version 20.2. Co-authored-by: adityamaru <[email protected]> Co-authored-by: Marcus Gartner <[email protected]>
adityamaru
added a commit
to adityamaru/cockroach
that referenced
this issue
Aug 8, 2023
Similar to cockroachdb#107570 this is a short term fix for when an a query is executed with an AS OF SYSTEM TIME picks a transaction timestamp before the job_info migration has run. In which case parts of the jobs infrastructure will attempt to query the job_info column even though it doesn't exist at the transaction's timestamp. As a short term fix, when we encounter an UndefinedObject error for the job_info table we generate a synthetic retryable error so that the txn is pushed to a higher timestamp at which the upgrade will have completed and the job_info table will be visible. The longer term fix is being tracked in cockroachdb#106764. On master I can no longer reproduce the failure in cockroachdb#105032 but on 23.1 with this change I can successfully run 30 iterations of the test on a seed (-8690666577594439584) which previously saw occurrences of this flake. Fixes: cockroachdb#103239 Fixes: cockroachdb#105032 Release note: None
craig bot
pushed a commit
that referenced
this issue
Aug 12, 2023
108357: jobs: fix mixed-version jobs flake r=knz a=adityamaru Similar to #107570 this is a short term fix for when an a query is executed with an AS OF SYSTEM TIME picks a transaction timestamp before the job_info migration has run. In which case parts of the jobs infrastructure will attempt to query the job_info column even though it doesn't exist at the transaction's timestamp. As a short term fix, when we encounter an UndefinedObject error for the job_info table we generate a synthetic retryable error so that the txn is pushed to a higher timestamp at which the upgrade will have completed and the job_info table will be visible. The longer term fix is being tracked in #106764. On master I can no longer reproduce the failure in #105032 but on 23.1 with this change I can successfully run 30 iterations of the test on a seed (-8690666577594439584) which previously saw occurrences of this flake. Fixes: #103239 Fixes: #105032 Release note: None 108583: rangefeed: deflake `TestBudgetReleaseOnOneStreamError` r=erikgrinaker a=erikgrinaker The test could fail with `REASON_SLOW_CONSUMER` if the registration goroutine did not drain the queue in time (1 ms). Increase the timeout. Resolves #108555. Epic: none Release note: None Co-authored-by: adityamaru <[email protected]> Co-authored-by: Erik Grinaker <[email protected]>
blathers-crl bot
pushed a commit
that referenced
this issue
Aug 12, 2023
Similar to #107570 this is a short term fix for when an a query is executed with an AS OF SYSTEM TIME picks a transaction timestamp before the job_info migration has run. In which case parts of the jobs infrastructure will attempt to query the job_info column even though it doesn't exist at the transaction's timestamp. As a short term fix, when we encounter an UndefinedObject error for the job_info table we generate a synthetic retryable error so that the txn is pushed to a higher timestamp at which the upgrade will have completed and the job_info table will be visible. The longer term fix is being tracked in #106764. On master I can no longer reproduce the failure in #105032 but on 23.1 with this change I can successfully run 30 iterations of the test on a seed (-8690666577594439584) which previously saw occurrences of this flake. Fixes: #103239 Fixes: #105032 Release note: None
adityamaru
added a commit
that referenced
this issue
Aug 18, 2023
In #106762 we noticed that if a query is executed with an AS OF SYSTEM TIME clause that picks a transaction timestamp before the job_type migration, then parts of the jobs infrastructure will attempt to query the job_type column even though it doesn't exist at the transaction's timestamp. As a short term fix, when we encounter an `UndefinedColumn` error for the `job_type` column in `crdb_internal.jobs` we generate a synthetic retryable error so that the txn is pushed to a higher timestamp at which the upgrade will have completed and the `job_type` column will be visible. The longer term fix is being tracked in #106764. We are intentionally approaching this issue with a whack-a-mole approach to stabilize the tests the are running into this issue. We think time is better spent designing and investing in the longer term solution that will be tracked in #106764. Fixes: #107169 Informs: #106762 Release note: None
adityamaru
added a commit
that referenced
this issue
Aug 18, 2023
Similar to #107570 this is a short term fix for when an a query is executed with an AS OF SYSTEM TIME picks a transaction timestamp before the job_info migration has run. In which case parts of the jobs infrastructure will attempt to query the job_info column even though it doesn't exist at the transaction's timestamp. As a short term fix, when we encounter an UndefinedObject error for the job_info table we generate a synthetic retryable error so that the txn is pushed to a higher timestamp at which the upgrade will have completed and the job_info table will be visible. The longer term fix is being tracked in #106764. On master I can no longer reproduce the failure in #105032 but on 23.1 with this change I can successfully run 30 iterations of the test on a seed (-8690666577594439584) which previously saw occurrences of this flake. Fixes: #103239 Fixes: #105032 Release note: None
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-cluster-upgrades
A-sql-execution
Relating to SQL execution.
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
Describe the problem
The 'AS OF SYSTEM TIME' clause allows users to pick the logical timestamp to execute a query at. When running 'AS OF SYSTEM TIME' queries, sql uses descriptors from the provided timestamp. This could cause problems when combined with serial major version upgrades and migrations.
Consider the 22.1, 22.2, and 23.1 upgrade chain. 23.1 is not guaranteed to be compatible with 22.1 descriptors.
Example:
t0: cluster is running 22.1
t1: binary is upgraded to 22.2
t2: 22.2 migrations are run
t3: binary is upgraded to 23.1
t4: 23.1 migrations are run
t5: A query is run with a system time of t0.
In this example the 23.1 query would try to interpret the descriptors from t0, which may cause the query to return incorrect results.
This problem could impact any sub system that depends on version gates and migrations. See #106762 for an example that is not dependent on descriptors.
The easiest way to "fix" this problem would be to reject AS OF SYSTEM TIME queries that attempt to read logical timestamps that were written by a binary older than
clusterversion.BinaryMinSupportedVersionKey
.Jira issue: CRDB-29708
The text was updated successfully, but these errors were encountered: