First consider the following simple example calls to a WT instance with the same key:
- Write + Commit U1 at TS(20)
- Prepare U2 at TS(10)
- Commit U2 at any commit + durable timestamp (the exact values irrelevant)
When using the (patched, see WT-7815) ordered write timestamp assertion, WT will correctly call out this misuse when the transaction commits entirely because of the chosen prepare timestamp.
Now consider the same example, but with a restart:
- Set OldestTimestamp 1
- Write + Commit U1 at TS(20)
- Set StableTimestamp 20
- Take a stable checkpoint and restart WT
- Prepare U2 at TS(10)
- Commit U2 at any commit + durable timestamp
In the second example, the assertion does not fire, but this out of order usage is still problematic and must be avoided from unintentionally happening.
- depends on
-
WT-7992 Provide API to return the last key in a table regardless of visibility
- Closed
- is duplicated by
-
WT-7819 information for ordered write timestamp assertion discarded after restart
- Closed
-
WT-7821 information for ordered write timestamp assertion discarded after restart
- Closed
-
WT-7822 information for ordered write timestamp assertion discarded after restart
- Closed
-
WT-7823 information for ordered write timestamp assertion discarded after restart
- Closed
-
WT-7824 information for ordered write timestamp assertion discarded after restart
- Closed
- is related to
-
SERVER-58409 Startup RecordId initialization is flawed with durable history and reconstructing prepared transactions
- Closed