-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
kvserver: add merged SSTTimestampToRequestTimestamp
param for AddSSTable
#76110
kvserver: add merged SSTTimestampToRequestTimestamp
param for AddSSTable
#76110
Conversation
638261c
to
193224e
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.
Reviewed 1 of 12 files at r2.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @dt and @erikgrinaker)
pkg/roachpb/api.proto, line 1645 at r2 (raw file):
bytes data = 2; // UpdateToRequestTimestamp updates all MVCC timestamps in the SST from the
(drive by comment. And the confusion may be limited to me so feel free to ignore.)
I found the "UpdateToRequestTimestamp updates all" and "parameter timestamp" phrasing a bit confusing. It also seemed that this was the timestamp to update to, when it is actually the timestamp in the sstable. How about something like:
// CurrentSSTableTimestampToRewrite when non-empty serves the following purpose:
// - It is the guaranteed timestamp of all entries in the sstable. This implies that the sstable only contains versioned keys.
// - It tells the proposal evaluator that if the request timestamp is not equal to this CurrentSSTableTimestampToRewrite, the evaluator must rewrite the sstable to the request timestamp.
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! 0 of 0 LGTMs obtained (waiting on @dt and @sumeerbhola)
pkg/roachpb/api.proto, line 1645 at r2 (raw file):
Previously, sumeerbhola wrote…
(drive by comment. And the confusion may be limited to me so feel free to ignore.)
I found the "UpdateToRequestTimestamp updates all" and "parameter timestamp" phrasing a bit confusing. It also seemed that this was the timestamp to update to, when it is actually the timestamp in the sstable. How about something like:
// CurrentSSTableTimestampToRewrite when non-empty serves the following purpose:
// - It is the guaranteed timestamp of all entries in the sstable. This implies that the sstable only contains versioned keys.
// - It tells the proposal evaluator that if the request timestamp is not equal to this CurrentSSTableTimestampToRewrite, the evaluator must rewrite the sstable to the request timestamp.
I like the concrete phrasing of the parameter's purpose. I don't love the name though. But names are hard. Maybe SSTTimestampToRequestTimestamp
?
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! 0 of 0 LGTMs obtained (waiting on @dt and @erikgrinaker)
pkg/roachpb/api.proto, line 1645 at r2 (raw file):
Previously, erikgrinaker (Erik Grinaker) wrote…
I like the concrete phrasing of the parameter's purpose. I don't love the name though. But names are hard. Maybe
SSTTimestampToRequestTimestamp
?
I'm fine with whatever name you come up with
193224e
to
c059516
Compare
UpdateToRequestTimestamp
param for AddSSTable
SSTTimestampToRequestTimestamp
param for AddSSTable
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! 0 of 0 LGTMs obtained (waiting on @dt and @sumeerbhola)
pkg/roachpb/api.proto, line 1645 at r2 (raw file):
Previously, sumeerbhola wrote…
I'm fine with whatever name you come up with
Renamed the parameter and reworded the comment.
c059516
to
9025553
Compare
Pebble has been bumped, so this is good to go now. |
7ec382e
to
d01423d
Compare
This patch adds `Timestamp.IsSet()`, which is the inverse of `IsEmpty()`. In complex boolean expressions, `IsSet()` is significantly easier to parse than `!IsEmpty()`, which can avoid mistakes. Release note: None
This makes `testing.T` the first parameter, as is customary, and replaces the unnecessary `Context` parameter with a background context as this is only used for logging. Release note: None
cab0e29
to
b384341
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.
Some nits about naming and comments. Otherwise seems good.
…STable` This merges the `AddSSTable` parameters `WriteAtRequestTimestamp` and `SSTTimestamp` into a new `SSTTimestampToRequestTimestamp` parameter. This parameter specifies the MVCC timestamp of all existing timestamps in the SST, which will be rewritten to the request timestamp if they differ (e.g. if the request gets pushed). Both of the replaced parameters are new in 22.1, so this does not require a version gate and allows changing the type of one of the existing Protobuf fields. Release note: None
b384341
to
ef6a82b
Compare
TFTR! bors r=aliher1911 |
Build succeeded: |
hlc: add
Timestamp.IsSet()
This patch adds
Timestamp.IsSet()
, which is the inverse ofIsEmpty()
. In complex boolean expressions,IsSet()
is significantlyeasier to parse than
!IsEmpty()
, which can avoid mistakes.Release note: None
testutils/sstutil: tweak
MakeSST()
parametersThis makes
testing.T
the first parameter, as is customary, andreplaces the unnecessary
Context
parameter with a background contextas this is only used for logging.
Release note: None
kvserver: add merged
UpdateToRequestTimestamp
param forAddSSTable
This merges the
AddSSTable
parametersWriteAtRequestTimestamp
andSSTTimestamp
into a newSSTTimestampToRequestTimestamp
parameter.This parameter specifies the MVCC timestamp of all existing timestamps
in the SST, which will be rewritten to the request timestamp if they
differ (e.g. if the request gets pushed).
Both of the replaced parameters are new in 22.1, so this does not
require a version gate and allows changing the type of one of the
existing Protobuf fields.
Release note: None