Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
65741: kvserver: don't reset local keys in tscache on r1 lease move r=andreimatei a=andreimatei applyReadSummaryToTimestampCache had a bug in how it dealt with r1's descriptor: it bumped the timestamp cache over the whole keyspace that the descriptor declared ([\x00,\x02)). That's bad, because it includes the \x01... keys. That's the "local" keyspace, which doesn't belong to any range in particular (so, r1's descriptor is arguably lying). Bumping the timestamp cache over the local keyspace had the consequence (maybe among others) that the txn tombstone keys were included, leading to transactions being aborted when they came to create their txn record because the bumped timestamp cache was saying that there might have been a tombstone in there. Release note: A bug causing transactions to be spuriously aborted in rare circumstances has been fixed. 66132: Auto-create docs issues when PRs with valid release notes are merged r=yzdocs a=yzdocs Fixes #59546 Implement a script run by a TeamCity build configuration that auto-creates an issue in the docs repo when a CRDB PR is merged, and that PR contains at least one commit with at least one valid release note that is not related to bug fix. Release note: None Dependent upon https://github.com/cockroachdb/dev-inf/issues/447 66165: kvclient: protect agaist DelRange with limit running as 1PC r=andreimatei a=andreimatei Such a request is dangerous because it can be very expensive. Because of how our "intent span" collection works, for requests from the EndTransaction batch, the intents they've laid down are inferred from the request, not from the response (since there's no opportunity to get a response before the intents need to be attached to the ET). This has potentially catastrophic consequences for DeleteRanges with limits in the ET batch - the limit is ignored for the purposes of tracking the intents. If the batch happens to also have a BeginTransaction, and if we manage to execute it as a 1PC (so, the DistSender doesn't need to split it and the store manages to execute it as 1PC), then I think we're fine - there's no intents to speak of and the ET is ignored. If it's not executed as a 1PC, however, the cleanup process is going to scan the whole key span specified in the DeleteRange, with no respect for the limit. This patch has the DistSender check for and reject such requests. Touches #37457 Release note: None Co-authored-by: Andrei Matei <[email protected]> Co-authored-by: YZ Chin <[email protected]>
- Loading branch information