roachtest: cdc/sink-chaos/rangefeed=true failed #43735
Assignees
Labels
branch-master
Failures and bugs on the master branch.
C-test-failure
Broken test (automatically or manually discovered).
O-roachtest
O-robot
Originated from a bot.
Milestone
Comments
cockroach-teamcity
added
C-test-failure
|
(roachtest).cdc/sink-chaos/rangefeed=true failed on master@2739821b911d777fa2a927295d699b559360a802: More
Artifacts: /cdc/sink-chaos/rangefeed=true See this test on roachdash |
|
Most recent failure was fixed in #45078. |
|
(roachtest).cdc/sink-chaos/rangefeed=true failed on master@c473f40078994551cebcbe00fdbf1fa388957658: More
Artifacts: /cdc/sink-chaos/rangefeed=true See this test on roachdash |
|
(roachtest).cdc/sink-chaos/rangefeed=true failed on master@793a9200c16693aff32aa6a4dd9d8bbcbddb30aa: More
Artifacts: /cdc/sink-chaos/rangefeed=true See this test on roachdash |
|
(roachtest).cdc/sink-chaos/rangefeed=true failed on master@69dc87d68addedf2fabfb2b14c098cfb35b5f3d0: More
Artifacts: /cdc/sink-chaos/rangefeed=true See this test on roachdash |
|
(roachtest).cdc/sink-chaos/rangefeed=true failed on master@f5585e933a097b53242d8d5800127b821a9a4d41: More
Artifacts: /cdc/sink-chaos/rangefeed=true See this test on roachdash |
|
(roachtest).cdc/sink-chaos/rangefeed=true failed on master@5a3d0c9539a671f0e55b680d3021b18dde9d190d: More
Artifacts: /cdc/sink-chaos/rangefeed=true See this test on roachdash |
|
(roachtest).cdc/sink-chaos/rangefeed=true failed on master@b5f030223fbcf22e806c48a3c46e74a73a54f50f: More
Artifacts: /cdc/sink-chaos/rangefeed=true See this test on roachdash |
|
(roachtest).cdc/sink-chaos/rangefeed=true failed on master@d571624ae4f833c49c717728a74cc7be78a791f0: More
Artifacts: /cdc/sink-chaos/rangefeed=true See this test on roachdash |
|
|
Same issue as #46290. Tracking over there. |
nvanbenschoten
added a commit
to nvanbenschoten/cockroach
that referenced
this issue
Mar 21, 2020
Fixes cockroachdb#46290. Fixes cockroachdb#43735. 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.
craig bot
pushed a commit
that referenced
this issue
Mar 23, 2020
46391: kv/concurrency: never regress timestamp in lockTable on lock acquisition r=sumeerbhola a=nvanbenschoten Fixes #46290. Fixes #43735. Fixes #41425. Fixes #43809. 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. This is a fairly large PR, but there's only a single line of non-testing code touched. 46415: sql: misc savepoint fixes r=andreimatei a=knz Fixes #46372 Release justification: bug fixes and low-risk updates to new functionality These commits correct a few gaps in the recent implementation. Co-authored-by: Nathan VanBenschoten <[email protected]> Co-authored-by: Raphael 'kena' Poss <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
(roachtest).cdc/sink-chaos/rangefeed=true failed on master@f180501b7c2ccb946d7f7c8944d5509b87cb0394:
Repro
Artifacts: /cdc/sink-chaos/rangefeed=true
powered by pkg/cmd/internal/issues
The text was updated successfully, but these errors were encountered: