-
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
optbuilder: always select tombstone index using the index ordinal #137361
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 5 of 5 files at r1, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @mgartner and @michae2)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the quick fix! I left a few minor suggestions.
Reviewed 5 of 5 files at r1, all commit messages.
Reviewable status: complete! 2 of 0 LGTMs obtained (waiting on @michae2 and @mw5h)
-- commits
line 25 at r1:
nit: It's good to mention what released versions the bug is present in. This note is automatically sent to the docs team to be added to release notes.
pkg/sql/opt/cat/table.go
line 369 at r1 (raw file):
// tombstones for the enforcement of this uniqueness constraint, or -1 if this // constraint is not enforceable with tombstones. TombstoneIndexOrdinal() int
nit: Make the return type IndexOrdinal
to make the API a bit more clear and consistent
Might be slightly more idiomatic to return (_ IndexOrdinal, ok bool)
to signify whether the tombstone can be used — up to you.
pkg/sql/opt/optbuilder/mutation_builder_unique.go
line 55 at r1 (raw file):
// partitions of a unique index with implicit partitioning columns. if mb.b.evalCtx.TxnIsoLevel != isolation.Serializable { if tombstoneIndexID := u.TombstoneIndexOrdinal(); tombstoneIndexID != -1 {
nit: I'd avoid "ID" in the name of this variable (and below) since its an ordinal not an ID.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 5 of 5 files at r1, all commit messages.
Reviewable status: complete! 3 of 0 LGTMs obtained (waiting on @mw5h)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: complete! 3 of 0 LGTMs obtained (waiting on @mw5h)
Previously, mgartner (Marcus Gartner) wrote…
nit: It's good to mention what released versions the bug is present in. This note is automatically sent to the docs team to be added to release notes.
Done
pkg/sql/opt/cat/table.go
line 369 at r1 (raw file):
Previously, mgartner (Marcus Gartner) wrote…
nit: Make the return type
IndexOrdinal
to make the API a bit more clear and consistentMight be slightly more idiomatic to return
(_ IndexOrdinal, ok bool)
to signify whether the tombstone can be used — up to you.
Done
pkg/sql/opt/optbuilder/mutation_builder_unique.go
line 55 at r1 (raw file):
Previously, mgartner (Marcus Gartner) wrote…
nit: I'd avoid "ID" in the name of this variable (and below) since its an ordinal not an ID.
Done!
Previously, the index to which tombstones would be written to enforce uniqueness was chosen using the ordinal of uniqueness constraint, which happens to be the same as the index ordinal if no non-unique indexes precede the unique indexes on a relation. However, if a non-unique index precedes a unique index, we will erroneously apply the uniqueness check to that index. In most cases, this will cause queries to fail on an assertion within the row helper code. However, a mixture of serializable and non-serializable mutations and some sequences of index additions and non-serializable mutations can cause uniqueness to be violated. This impacts all regional by row tables with uniqueness constraints that do not include the region which are mutated under non-serializable isolations. This patch plumbs through the index ordinal so that the proper index will be checked for uniqueness in all cases. Fixes: cockroachdb#137341 Release note (bug fix): Regional by row tables with uniqueness constraints where the region is not part of those uniqueness constraints and which also contain non-unique indices will now have that uniqueness properly enforced when modified at READ-COMMITTED isolation. This bug was introduced in release 24.3.0.
bors r+ |
👎 Rejected by label |
TYFTR |
bors r+ |
👎 Rejected by label |
bors r+ |
Based on the specified backports for this PR, I applied new labels to the following linked issue(s). Please adjust the labels as needed to match the branches actually affected by the issue(s), including adding any known older branches. Issue #137341: branch-release-24.3.1-rc. 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf. |
Previously, the index to which tombstones would be written to enforce uniqueness was chosen using the ordinal of uniqueness constraint, which happens to be the same as the index ordinal if no non-unique indexes precede the unique indexes on a relation. However, if a non-unique index precedes a unique index, we will erroneously apply the uniqueness check to that index. In most cases, this will cause queries to fail on an assertion within the row helper code.
However, a mixture of serializable and non-serializable mutations and some sequences of index additions and non-serializable mutations can cause uniqueness to be violated. This impacts all regional by row tables with uniqueness constraints that do not include the region which are mutated under non-serializable isolations.
This patch plumbs through the index ordinal so that the proper index will be checked for uniqueness in all cases.
Fixes: #137341
Release note (bug fix): Regional by row tables with uniqueness constraints where the region is not part of those uniqueness constraints and which also contain non-unique indices will now have that uniqueness properly enforced when modified at READ-COMMITTED isolation. This bug was introduced in
release 24.3.0.