-
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
protectedts: fix panic when fetching protectedts records #79787
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 3 of 3 files at r1, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @arulajmani)
Previously, we incorrectly assumed that all records in the `system.protectedts_records` table would have a non NULL target column. While this is enforced for all protected timestamp records written in a 22.1+ cluster, this is not true for records that might have been prior to the 22.1 cluster version being finalized. This change makes the method responsible for reading protectedts records more defensive when encountering a NULL target column. Fixes: cockroachdb#79684 Release note: None
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 1 of 3 files at r1, 2 of 2 files at r2, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (and 1 stale) (waiting on @adityamaru)
pkg/kv/kvserver/protectedts/ptstorage/storage.go, line 421 at r2 (raw file):
if !ok { // We are reading a pre-22.1 protected timestamp record that has a NULL // target column, so there is nothing more to do.
nit: add a TODO to remove this code in the next release?
I promise I'll remember, don't make me push again 😋 |
TFTRs! bors r+ |
Build succeeded: |
Previously, we incorrectly assumed that all records in the
system.protectedts_records
table would have a non NULL targetcolumn. While this is enforced for all protected timestamp
records written in a 22.1+ cluster, this is not true for records
that might have been prior to the 22.1 cluster version being
finalized.
This change makes the method responsible for reading protectedts
records more defensive when encountering a NULL target column.
Fixes: #79684
Release note: None