sql/row: avoid NegotiateAndSend on a multi-batch request#69350
sql/row: avoid NegotiateAndSend on a multi-batch request#69350craig[bot] merged 1 commit intocockroachdb:masterfrom
Conversation
nvb
left a comment
There was a problem hiding this comment.
Reviewed 3 of 3 files at r1, all commit messages.
Reviewable status:complete! 1 of 0 LGTMs obtained (waiting on @otan)
pkg/sql/row/kv_fetcher.go, line 68 at r1 (raw file):
sendFn = func(ctx context.Context, ba roachpb.BatchRequest) (br *roachpb.BatchResponse, _ error) { ba.RoutingPolicy = roachpb.RoutingPolicy_NEAREST ba.BoundedStaleness = bsHeader
We don't want this, right? Won't this hit the assertion we just added on the Send path? Do we need a test that intentionally hits the Send path?
pkg/sql/row/kv_fetcher.go, line 75 at r1 (raw file):
if !negotiated { ba.BoundedStaleness = bsHeader br, pErr = txn.NegotiateAndSend(ctx, ba)
Do you mind opening an issue for me to add a test to txn_external_test.go that ensures that a bounded staleness read that returns a resume span still negotiates correctly and fixes the transaction timestamp?
Avoid the double NegotiateAndSend on a bounded staleness request if there are multiple column families for the given row by tracking whether a negotiate was already made. If so, use Send, as SetFixedTimestamp would already have the correct value. Release justification: fix to new feature Release note: None
05125ef to
d490a28
Compare
otan
left a comment
There was a problem hiding this comment.
Reviewable status:
complete! 0 of 0 LGTMs obtained (and 1 stale) (waiting on @nvanbenschoten)
pkg/sql/row/kv_fetcher.go, line 68 at r1 (raw file):
Previously, nvanbenschoten (Nathan VanBenschoten) wrote…
We don't want this, right? Won't this hit the assertion we just added on the Send path? Do we need a test that intentionally hits the Send path?
urgh! i rebased this wrong. my bad. this test would have failed (...flakily / under stress...)
|
bors r=nvanbenschoten |
|
Build succeeded: |
Fixes cockroachdb#69386. In cockroachdb#69350, we began relying on the previously unspecified behavior of Txn.NegotiateAndSend that negotiation was completed across all read spans in a request, even if the request itself was paginated. This commit clarifies this contract. It also adds client and server-side tests that exercise the behavior. Release justification: added testing for new functionality
Fixes cockroachdb#69386. In cockroachdb#69350, we began relying on the previously unspecified behavior of Txn.NegotiateAndSend that negotiation was completed across all read spans in a request, even if the request itself was paginated. This commit clarifies this contract. It also adds client and server-side tests that exercise the behavior. Release justification: added testing for new functionality
69481: kv: specify + test behavior of NegotiateAndSend with paginated reads r=nvanbenschoten a=nvanbenschoten Fixes #69386. In #69350, we began relying on the previously unspecified behavior of Txn.NegotiateAndSend that negotiation was completed across all read spans in a request, even if the request itself was paginated. This commit clarifies this contract. It also adds client and server-side tests that exercise the behavior. Release justification: added testing for new functionality 69489: roachtest/follower-reads: adopt bounded staleness reads r=nvanbenschoten a=nvanbenschoten This commit expands the existing `follower-reads` roachtest with four new variants: - `follower-reads/survival=region/locality=global/reads=bounded-staleness` - `follower-reads/survival=region/locality=regional/reads=bounded-staleness` - `follower-reads/survival=zone/locality=global/reads=bounded-staleness` - `follower-reads/survival=zone/locality=regional/reads=bounded-staleness` As the names indicate, these four variants perform bounded staleness reads over different cluster topologies and assert that the reads are served from follower replicas. Release note: None Release justification: testing only Co-authored-by: Nathan VanBenschoten <nvanbenschoten@gmail.com>
Avoid the double NegotiateAndSend on a bounded staleness request if
there are multiple column families for the given row by tracking
whether a negotiate was already made. If so, use Send, as
SetFixedTimestamp would already have the correct value.
Release justification: fix to new feature
Resolves: #69063
Release note: None