-
- Downloads
Fix a bug with SSI and prepared transactions:
If there's a dangerous structure T0 ---> T1 ---> T2, and T2 commits first, we need to abort something. If T2 commits before both conflicts appear, then it should be caught by OnConflict_CheckForSerializationFailure. If both conflicts appear before T2 commits, it should be caught by PreCommit_CheckForSerializationFailure. But that is actually run when T2 *prepares*. Fix that in OnConflict_CheckForSerializationFailure, by treating a prepared T2 as if it committed already. This is mostly a problem for prepared transactions, which are in prepared state for some time, but also for regular transactions because they also go through the prepared state in the SSI code for a short moment when they're committed. Kevin Grittner and Dan Ports
Showing
- src/backend/storage/lmgr/predicate.c 35 additions, 3 deletionssrc/backend/storage/lmgr/predicate.c
- src/test/regress/expected/prepared_xacts.out 3 additions, 3 deletionssrc/test/regress/expected/prepared_xacts.out
- src/test/regress/expected/prepared_xacts_1.out 1 addition, 1 deletionsrc/test/regress/expected/prepared_xacts_1.out
- src/test/regress/sql/prepared_xacts.sql 1 addition, 1 deletionsrc/test/regress/sql/prepared_xacts.sql
Loading
Please register or sign in to comment