release-2.1: storageccl: tolerate rewriting keys with fewer columns than expected #36006
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport 1/1 commits from #35750.
/cc @cockroachdb/release
When rewriting a key, if it belongs to an index in which another is interleaved, once we rewrite past the table/index ID prefix, we previously would assume we had to skip exactly the number of columns indexed before checking if there was an interleave child ID to rewrite.
However, if a span's start or end key does not include all the index columns, this assumption is invalid. It is unclear why we'd have such a span boundary, but if we do, the key rewriter has technically done its job if it rewrites all the IDs in the prefix of a key and then finds the key ends in the middle of the column values. While unexpected, strictly from the point of view of the rewriter, the key's IDs are rewritten and it can return.
Release note (enterprise change): Fix a bug in RESTORE where some unusual range boundaries in interleaved tables caused an error.