Skip to content
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

Merged
merged 1 commit into from
Dec 12, 2024

Conversation

mw5h
Copy link
Contributor

@mw5h mw5h commented Dec 12, 2024

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.

@mw5h mw5h added backport Label PR's that are backports to older release branches backport-24.3.x Flags PRs that need to be backported to 24.3 labels Dec 12, 2024
@mw5h mw5h requested review from mgartner, rytaft and michae2 December 12, 2024 20:56
@mw5h mw5h self-assigned this Dec 12, 2024
@mw5h mw5h requested a review from a team as a code owner December 12, 2024 20:56
@cockroach-teamcity
Copy link
Member

This change is Reviewable

Copy link
Collaborator

@rytaft rytaft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm: thanks for the quick fix!

Reviewed 5 of 5 files at r1, all commit messages.
Reviewable status: :shipit: complete! 1 of 0 LGTMs obtained (waiting on @mgartner and @michae2)

Copy link
Collaborator

@mgartner mgartner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm: Thanks for the quick fix! I left a few minor suggestions.

Reviewed 5 of 5 files at r1, all commit messages.
Reviewable status: :shipit: 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.

Copy link
Collaborator

@michae2 michae2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm: Nice fix!

Reviewed 5 of 5 files at r1, all commit messages.
Reviewable status: :shipit: complete! 3 of 0 LGTMs obtained (waiting on @mw5h)

Copy link
Contributor Author

@mw5h mw5h left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: :shipit: complete! 3 of 0 LGTMs obtained (waiting on @mw5h)


-- commits line 25 at r1:

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 consistent

Might 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.
@mw5h
Copy link
Contributor Author

mw5h commented Dec 12, 2024

bors r+

@craig
Copy link
Contributor

craig bot commented Dec 12, 2024

👎 Rejected by label

@mw5h
Copy link
Contributor Author

mw5h commented Dec 12, 2024

TYFTR

@mw5h
Copy link
Contributor Author

mw5h commented Dec 12, 2024

bors r+

@craig
Copy link
Contributor

craig bot commented Dec 12, 2024

👎 Rejected by label

@mw5h mw5h added backport-24.3.1-rc and removed backport Label PR's that are backports to older release branches backport-24.3.1-rc labels Dec 12, 2024
@mw5h
Copy link
Contributor Author

mw5h commented Dec 12, 2024

bors r+

@craig craig bot merged commit cccfc7c into cockroachdb:master Dec 12, 2024
20 of 22 checks passed
Copy link

blathers-crl bot commented Dec 12, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport-24.3.x Flags PRs that need to be backported to 24.3
Projects
None yet
Development

Successfully merging this pull request may close these issues.

sql: internal error from uniqueness checks during INSERT to RBR table under read-committed
6 participants