forked from cockroachdb/cockroach
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
kv: perform recovery on rollback of staging transaction record
Fixes cockroachdb#48301. During a transaction rollback (i.e. an `EndTxn(abort)`), if the request arrives to find that the transaction record is STAGING, it can only move it to ABORTED if it is *not* already implicitly committed. On the commit path, the transaction coordinator is deliberate to only ever issue an `EndTxn(commit)` once the transaction has reached an implicit commit state. However, on the rollback path, the transaction coordinator does not make the opposite guarantee that it will never issue an `EndTxn(abort)` once the transaction has reached (or if it still could reach) an implicit commit state. As a result, on the rollback path, we don't trust the transaction's coordinator to be an authoritative source of truth about whether the transaction is implicitly committed. In other words, we don't consider this `EndTxn(abort)` to be a claim that the transaction is not implicitly committed. The transaction's coordinator may have just given up on the transaction before it heard the outcome of a commit attempt. So in this case, we now return an `IndeterminateCommitError` during evaluation to trigger the transaction recovery protocol and transition the transaction record to a finalized state (COMMITTED or ABORTED). This was one of the two alternatives described in cockroachdb#48301. The other option was to lock down the txn client to attempt to make the guarantee that rollbacks will only be performed if the client is certain that the transaction is not currently in and can no longer ever enter the implicit commit state. I was previously drawn to this other approach because it would avoid the need for transaction recovery during the rollback of a staging txn. However, I don't think it's possible to make such a guarantee in all cases due to the possibility of ambiguity. To eliminate this ambiguity, there are cases where a transaction's coordinator would need to query the result of writes, which turns out to be analogous to the transaction recovery protocol. So instead of trying to make the guarantee in all cases, I'd rather make rollbacks safe in all cases and then later explore selectively opting in to skipping txn recovery in specific cases where the client can definitively guarantee that the it is rolling back a staging transaction that is not implicitly committed. I don't expect this to be needed immediately. Release note (bug fix): fixed a rare race condition that could lead to client-visible errors that looked like "found ABORTED record for implicitly committed transaction". These errors were harmless in that they did not indicate data corruption, but they could be disruptive to clients.
- Loading branch information
1 parent
659fe19
commit ac7094e
Showing
4 changed files
with
162 additions
and
26 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters