teamcity: failed test: TestPlannerLogic #34911
Assignees
Labels
Milestone
Comments
cockroach-teamcity
added
C-test-failure
|
This doesn't seem to be a planning issue. The diff shows these two additional rows at the end of the log: I'm assuming this is a test flake. @nvanbenschoten, do you know what's causing these to be added? Are they non-deterministic? Do we need to somehow exclude them from expected trace results? |
|
This looks like a duplicate of #33720, where we also saw an unexpected push. Without digging in too deeply here, I suspect that we're seeing essentially what @andreimatei speculated in #33720 (comment): a previous transaction may have failed to asynchronously clean up its intent in time and we're running into it in a later transaction. We're already ignoring a number of trace messages here. We might just want to ignore this source of non-determinism as well. |
Merged
andy-kimball
added a commit
to andy-kimball/cockroach
that referenced
this issue
Feb 21, 2019
Filter out PushTxn/ResolveIntent/SystemConfigSpan trace messages, since they represent intent cleanup / system activity from earlier operations that interferes with subsequent tests. This was already being done in other variations, so this commit extends that to all the variations that are doing filtering of messages. Fixes cockroachdb#34911 Fixes cockroachdb#35093 Release note: None
craig bot
pushed a commit
that referenced
this issue
Feb 21, 2019
35081: sql: Fix test flake r=andy-kimball a=andy-kimball Filter out PushTxn/ResolveIntent trace messages, since they represent intent cleanup from earlier operations that interferes with subsequent tests. This was already being done in other variations, so this commit extends that to all the variations that are doing filtering of messages. Fixes #34911 Release note: None 35086: mvcc: don't write below provisional commit timestamp on WriteTooOld errors r=tbg a=nvanbenschoten Fixes #34853. This change fixes #34853, which appears to have been broken by 57d0201#diff-41e9e1b7829f8e25daeb564f42c26017L1514. That change made it so that intents are now written at a transaction's provisional commit timestamp instead of its original timestamp (which is fantastic!). In doing so, it removed special-purpose code to forward the `MVCCLogicalOpDetails` timestamp to the provisional commit timestamp of the transaction because it assumed that the new `writeTimestamp` variable that the change introduced already assumed this role. Unfortunately, the change allowed this `writeTimestamp` variable to regress below the transaction's provisional commit timestamp in subtle cases where a committed value ended up between the transaction's original timestamp and its provisional commit timestamp (a case that generates `WriteTooOldError`s). In this case, we were replacing the `writeTimestamp` with the committed value's timestamp + 1 logical tick. This regression allowed `MVCCWriteIntentOp`s to look like they were ignoring closed timestamps. The fix was to either introduce the special purpose code again or to avoid letting `writeTimestamp` regress in this `WriteTooOldError` code path. This PR chose the latter solution. In doing so, this PR also improves upon the benefit already provided by #32487 - it reduces the number of intents that need to be moved on transaction commit. This is because it ensures that if a transaction has an original (read) timestamp below a committed value and a provisional commit (write) timestamp above a committed value, an intent left by that transaction will be in a "committable" state without a need to rewrite it during intent resolution. Release note: None 35112: kv: assert an absence of retries in TestTxnCoordSenderRetries r=tbg,andreimatei a=nvanbenschoten The test was only asserting that cases that should observe retries did, not the cases that should not observe retries did not. The PR also fixes `TestPropagateTxnOnError`, which wasn't really testing anything. We now set txn.Writing on the client, so it wasn't verifying what it thought it was. We switch it to assert that observed timestamps are propagated on error instead. 35118: storage: Downgrade a spammy log message r=tbg a=bdarnell This log message only occurs on clusters with multiple stores per node, but on those clusters it fires multiple times per second. Release note: None Co-authored-by: Andrew Kimball <[email protected]> Co-authored-by: Nathan VanBenschoten <[email protected]> Co-authored-by: Ben Darnell <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The following tests appear to have failed on master (test): TestPlannerLogic/local, TestPlannerLogic/local: TestPlannerLogic/local/show_trace, TestPlannerLogic
You may want to check for open issues.
#1138761:
Please assign, take a look and update the issue accordingly.
The text was updated successfully, but these errors were encountered: