-
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: race condition with fast path for insert #43969
Comments
The change happens because statistics kick in and for such small tables, the FK checks end up being hash joins (because of #41701). The failure would show up again with more data in the tables. This should be 100% reproducible if the auto stats are turned off. |
The problem is that the optimizer chooses the |
The insert fast path doesn't work correctly when the FK checks use a non-unique index. This is rare, but it can happen when 1) the key is composite; 2) it is the primary key in the parent table; and 3) there is a non-unique secondary index on a subset of the primary key columns. In this case the secondary index is preferred because it contains fewer columns. The problem is that the lookup involves implicit columns and neither the fast path code nor the `EncodePartialIndexKey` code were equipped to handle this. This change adds logic to handle implicit columns. Note that the legacy path doesn't have this problem because it is always hardwired to use the unique index. Fixes cockroachdb#43969. Release note (bug fix): fixed internal error of the form "x FK cols, only y cols in index" in some cases when inserting into a table with foreign key references.
43960: importccl: move OnSuccess callback to Resume r=pbardea a=pbardea OnSuccess is not guaranteed to be called only once. In an effort to move away from using this callback the logic previously contained in OnSuccess for import is being moved into Resume with logic to ensure that it is only run once.e Release note (bug fix): Ensure the import cleanup is only run once. 44025: roachtest: update libpq blacklist r=rafiss a=rafiss A new test was added that is failing, and a different test was fixed upstream so it passes now. fixes #43345 Release note: none 44031: opt: fix insert fast path when using a non-unique index r=RaduBerinde a=RaduBerinde The insert fast path doesn't work correctly when the FK checks use a non-unique index. This is rare, but it can happen when 1) the key is composite; 2) it is the primary key in the parent table; and 3) there is a non-unique secondary index on a subset of the primary key columns. In this case the secondary index is preferred because it contains fewer columns. The problem is that the lookup involves implicit columns and neither the fast path code nor the `EncodePartialIndexKey` code were equipped to handle this. This change adds logic to handle implicit columns. Note that the legacy path doesn't have this problem because it is always hardwired to use the unique index. Fixes #43969. Release note (bug fix): fixed internal error of the form "x FK cols, only y cols in index" in some cases when inserting into a table with foreign key references. Co-authored-by: Paul Bardea <pbardea@gmail.com> Co-authored-by: Rafi Shamim <rafi@cockroachlabs.com> Co-authored-by: Radu Berinde <radu@cockroachlabs.com>
#42914 added a specialized execution operator that allows running foreign key checks before (or in parallel with) a mutation.
This seems to have created a race condition, which I discovered because of a test that started failing in the Hibernate repo. The test is org.hibernate.test.annotations.cid.CompositeIdTest.testSecondaryTableWithCompositeId, but here is how to reproduce the issue with just SQL from the CLI interface.
Run the following all at once by copy-pasting into the CLI:
The following error occurs
However, if I run the above statements one-by-one, with some time in between each one, it seems to work. Also, usually if I retry running the last statement (inserting into
TV_PROGRAM_EXT
), then it gets executed successfully.The text was updated successfully, but these errors were encountered: