Tags: kimmking/cockroach
Tags
Merge cockroachdb#46411 cockroachdb#46423 46411: sql,stmtdiagnostics: fix startup bug, extract subpackage for stmtdiagnostics r=ajwerner a=ajwerner This PR comes in 2 commits. The first is a critical bug fix for cockroachdb#46410 whereby queries could be issued before the server has started up. The second is aesthetic. The statement diagnostics registry deserves its own package; sql is a mess already, no need to make it worse. Release justification: bug fixes and low-risk updates to new functionality 46423: Add Marcus to AUTHORS r=mgartner a=mgartner Add myself to the AUTHORS file as part of onboarding. Release justification: no code changes Co-authored-by: Andrew Werner <ajwerner@cockroachlabs.com> Co-authored-by: Marcus Gartner <marcus@cockroachlabs.com>
kv/concurrency: never regress timestamp in lockTable on acquisition Fixes cockroachdb#46290. Fixes cockroachdb#43735. Fixes cockroachdb#41425. This change adjusts the lockTable to be more lenient to the timestamp of new lock acquisitions. Specifically, it lifts the restriction that all calls to AcquireLock use monotonically increasing timestamps. Instead, it properly handles apparent timestamp regressions by ratcheting lock timestamps instead of replacing them directly. This matches the corresponding behavior in MVCC: https://github.com/cockroachdb/cockroach/blob/92107b551bbafe54fddb496442c590cb6feb5d65/pkg/storage/mvcc.go#L1631 This leniency is needed for sequences of events like the following: - txn A acquires lock at epoch 1, ts 10 - txn B pushes txn A to ts 20 - txn B updates lock to ts 20 - txn A restarts at ts 15 without noticing that it has been pushes - txn A re-acquires lock at epoch 2, ts 15 - we hit the lock timestamp regression assertion We see this frequently in CDC roachtests because the rangefeed processor performs high-priority timestamp pushes on long-running transactions. Outside of CDC, this is rare in our system. Release note (bug fix): CDC no longer combines with long running transactions to trigger an assertion. Release justification: fixes a high-priority bug in existing functionality. The bug could crash a server if the right sequence of events occurred. This was typically rare, but was much more common when CDC was in use.
Merge cockroachdb#46411 cockroachdb#46423 46411: sql,stmtdiagnostics: fix startup bug, extract subpackage for stmtdiagnostics r=ajwerner a=ajwerner This PR comes in 2 commits. The first is a critical bug fix for cockroachdb#46410 whereby queries could be issued before the server has started up. The second is aesthetic. The statement diagnostics registry deserves its own package; sql is a mess already, no need to make it worse. Release justification: bug fixes and low-risk updates to new functionality 46423: Add Marcus to AUTHORS r=mgartner a=mgartner Add myself to the AUTHORS file as part of onboarding. Release justification: no code changes Co-authored-by: Andrew Werner <ajwerner@cockroachlabs.com> Co-authored-by: Marcus Gartner <marcus@cockroachlabs.com>
Merge pull request cockroachdb#46154 from nvanbenschoten/backport19.2… …-46085 release-19.2: kv/kvserver: use LAI from before split when setting initialMaxClosed
storage: paginage GC of abort span Partial (manual) backport of cockroachdb#45444. Release note: None
storage: paginage GC of abort span Partial (manual) backport of cockroachdb#45444. Release note: None
storage: 10 minute timeout for GC queue Release note: None
storage: 10 minute timeout for GC queue Release note: None
Merge cockroachdb#45295 45295: opt: set not-null aggregation cols for grouping ops r=andy-kimball a=andy-kimball Previously, aggregate columns were never marked as "not null". This commit marks them as not null in two cases: 1. If the aggregate function always returns a not-null value, such as the count function. 2. If the grouping operator is not scalar-group-by (because it can return null when input is empty), and all arguments to the aggregate function are not-null. Release note: None Co-authored-by: Andrew Kimball <andyk@cockroachlabs.com>
4372
Merge cockroachdb#44661 44661: kv: refresh less and retry more r=andreimatei a=andreimatei Before this patch, when the DistSender would split a batch into multiple sub-batches and one of the sub-batches fails, it would collect responses for the successful ones and return them together with the error. This used to be pretty important before we had write idempotency, because it allowed the span refresher to only retry an EndTxn without also retring other writes in that batch (which would have failed). Since we've gotten idempotency in the meantime, we can retry those other writes. In fact, it's arguably better to do it: there's a tradeoff between refreshing and retrying. Currently the span refresher needs to refresh the read spans of the successful sub-batches, which refresh is at risk of failing under contention. This patch makes the span refresher retry the whole batch without considering partial successes. With this patch, refreshing the partial successes is no longer needed because we'll retry those requests. In other words, we'll refresh less and retry more. The existing policy of refreshing more and retrying less will start to be applied inconsistenly with cockroachdb#44654, where we start refreshing when the client sees a WriteTooOld flag - but we're forced to refresh the whole batch. Besides the rationalizations above, this patch allows us to simplify code by not having to deal with both responses and errors. We can thus get rid of the enthralling comment on the client.Sender.Send() stating: " // The contract about whether both a response and an error can be // returned varies between layers. " Release note: None Co-authored-by: Andrei Matei <andrei@cockroachlabs.com>
PreviousNext