kv: properly handle intent pushes to synthetic timestamps#63800
kv: properly handle intent pushes to synthetic timestamps#63800craig[bot] merged 1 commit intocockroachdb:masterfrom
Conversation
|
This change is |
andreimatei
left a comment
There was a problem hiding this comment.
Reviewable status:
complete! 1 of 0 LGTMs obtained (waiting on @nvanbenschoten)
pkg/kv/kvserver/concurrency/lock_table_waiter.go, line 567 at r1 (raw file):
} func (w *lockTableWaiterImpl) pushHeader(req Request) roachpb.Header {
mind adding a comment to this function
pkg/kv/kvserver/concurrency/lock_table_waiter.go, line 618 at r1 (raw file):
// not come from an HLC clock, but it does not currently get marked as // so. See the TODO in roachpb.MakeTransaction. uncertaintyLimit = uncertaintyLimit.WithSynthetic(true)
should this WithSynthetic be moved up? And then Backwards above will make it non-synthetic on the other branch I think.
This commit reworks the timestamp that pushers use when pushing intents to synthetic timestamps. Usually, as of cockroachdb#59086, a pusher limits the timestamp that it pushes conflicting intents to using the local HLC clock. This is based on the assumption that it will be able to ignore any intent above the local HLC clock's reading using observed timestamps and a local uncertainty limit. However, this argument only holds if we expect to be able to use a local uncertainty limit when we return to read the pushed intent. Notably, local uncertainty limits can not be used to ignore intents with synthetic timestamps that would otherwise be in a reader's uncertainty interval. This is because observed timestamps do not apply to intents/values with synthetic timestamps. So if we know that we will be pushing an intent to a synthetic timestamp, we don't limit the value to a clock reading from the local clock. This came out of some exploration of kvnemesis. I don't think this was actually causing an issue, but it seemed like a potential source of an infinite push + conflict loop. Release note (bug fix): Read-write contention on GLOBAL tables no longer has a potential to thrash without making progress.
e0138db to
1dac4bb
Compare
nvb
left a comment
There was a problem hiding this comment.
Reviewable status:
pkg/kv/kvserver/concurrency/lock_table_waiter.go, line 567 at r1 (raw file):
Previously, andreimatei (Andrei Matei) wrote…
mind adding a comment to this function
Done.
pkg/kv/kvserver/concurrency/lock_table_waiter.go, line 618 at r1 (raw file):
Previously, andreimatei (Andrei Matei) wrote…
should this
WithSyntheticbe moved up? And thenBackwardsabove will make it non-synthetic on the other branch I think.
Yeah, good idea. Done.
|
bors r+ |
|
Build succeeded: |
This commit reworks the timestamp that pushers use when pushing intents
to synthetic timestamps. Usually, as of #59086, a pusher limits the
timestamp that it pushes conflicting intents to using the local HLC
clock. This is based on the assumption that it will be able to ignore
any intent above the local HLC clock's reading using observed timestamps
and a local uncertainty limit.
However, this argument only holds if we expect to be able to use a local
uncertainty limit when we return to read the pushed intent. Notably,
local uncertainty limits can not be used to ignore intents with
synthetic timestamps that would otherwise be in a reader's uncertainty
interval. This is because observed timestamps do not apply to
intents/values with synthetic timestamps. So if we know that we will be
pushing an intent to a synthetic timestamp, we don't limit the value to
a clock reading from the local clock.
This came out of some exploration of kvnemesis. I don't think this was
actually causing an issue, but it seemed like a potential source of an
infinite push + conflict loop.
Release note (bug fix): Read-write contention on GLOBAL tables no longer
has a potential to thrash without making progress.