-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication, Storage
-
Fully Compatible
-
ALL
-
-
Repl 2018-07-16, Repl 2018-07-30, Repl 2018-08-13
-
70
Our current prepareTransaction() logic might need some changes: currently, (1) we first log the prepare and get a timestamp T. And then (2) use this timestamp T to set the prepare timestamp in WiredTiger. Since (1) pushes the lastApplied timestamp to T and another transaction could start between (1) and (2), with lastApplied T as the read timestamp, it breaks the rule that prepare timestamp should be greater than any active read timestamp.
Here is what happened in BF-9432:
1. A started a transaction, did the insertion, and tried to prepare.
2. A called prepareTransaction() in session.cpp. It first logged the prepare and got a timestamp T. This operation also pushed the lastApplied timestamp to T.
3. B started a transaction with a read, the read timestamp is set to the lastApplied which is T.
4. A now tried to set the prepare timestamp to T in WiredTiger. It will cause a WiredTiger error that prepare timestamp being equal to an active read timestamp.
- has to be done before
-
SERVER-36023 Try to enable replica set transaction testing with the inMemory WT storage engine
- Closed
- is duplicated by
-
SERVER-35430 Abort a transaction if prepare fails
- Closed
- is related to
-
SERVER-35821 readConcern:snapshot transactions need a read timestamp <= WT's all_committed point
- Closed
-
SERVER-38499 Preparing transaction fails and triggers invariant if chosen timestamp is not greater than WiredTiger's latest active read timestamp
- Closed