-
Notifications
You must be signed in to change notification settings - Fork 465
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
db: enforce no split user keys in CheckOrdering #3085
db: enforce no split user keys in CheckOrdering #3085
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.
I wrote this because I was growing concerned about the complexity of the ingest codepath and the possibility we might violate this invariant by ingesting a user key into a level it already exists within. As far as I can tell, we're not doing that, but this stronger assertion will ensure it.
Reviewable status: 0 of 20 files reviewed, all discussions resolved (waiting on @aadityasondhi, @RaduBerinde, and @sumeerbhola)
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 20 of 20 files at r1, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @aadityasondhi, @jbowens, and @RaduBerinde)
format_major_version.go
line 222 at r1 (raw file):
} func (v FormatMajorVersion) orderingInvariants() manifest.OrderingInvariants {
Maybe add a comment that OrderingInvariants only get stricter as the format major version advances. So it is ok that someone retrieves an invariant and by the time it checks the invariant the FMV has advanced.
Adapt CheckOrdering to perform its overlap comparisons using the stricter requirement that adjacent files not contain the same user key. Since we still support the earlier format major versions that predate this requirement, this behavior is gated behind an OrderingInvariants enum variant determined by the active format major version. Some of the tests that use more recent format major versions still created test cases with split user keys, and they needed to be adjusted.
6cc49f3
to
1bfc681
Compare
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.
TFTR!
Reviewable status: 19 of 20 files reviewed, 1 unresolved discussion (waiting on @aadityasondhi, @RaduBerinde, and @sumeerbhola)
format_major_version.go
line 222 at r1 (raw file):
Previously, sumeerbhola wrote…
Maybe add a comment that OrderingInvariants only get stricter as the format major version advances. So it is ok that someone retrieves an invariant and by the time it checks the invariant the FMV has advanced.
Good call, done.
Adapt CheckOrdering to perform its overlap comparisons using the stricter requirement that adjacent files not contain the same user key. Since we still support the earlier format major versions that predate this requirement, this behavior is gated behind an OrderingInvariants enum variant determined by the active format major version.
Some of the tests that use more recent format major versions still created test cases with split user keys, and they needed to be adjusted.
Informs #3064.