-
Type: Improvement
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Storage Engines
-
5
-
Storage - Ra 2021-11-01, Storage - Ra 2021-11-15
Currently our timestamp transaction API allows the user to specify a commit timestamp after having already performed modifications. The user can then call session->timestamp_transaction which will timestamp subsequent database modifications. The prior modifications are left with WT_TS_NONE.
Upon commit the current commit timestamp on the transaction will then be applied to any of the modifications that are un-timestamped.
The net result is that updates that were done earlier in the transaction now have an older timestamp which is especially problematic if the the user called session->timestamp_transaction multiple times as the timestamp at the end of the transactions lifecycle should be higher than the ones used partway through. In scenarios where the user has applied multiple updates to the same key and left the earlier ones un-timestamped its likely that those updates will have out of order timestamps.
I am proposing we restrict this api to only allow session->timestamp_transaction on transactions that don't have modifications. Or if there are previous modifications it can only be called once. I suspect either way this would cause fallout in MongoDB testing.
The work in this ticket is to:
- Discuss the validity of the proposal.
- If accepted begin implementing and collaborate with a server engineer on resolving the mongodb fallout.
An alternative solution is to modify the timestamps of the un-timestamped modifications at the time of calling session->timestamp_transaction.
- depends on
-
SERVER-18934 Don't require storage engines to implement oplog visibility rules
- Backlog
- is depended on by
-
WT-8165 Commit timestamp assertions didn't catch invalid timestamps in specific scenario
- Backlog
- related to
-
WT-12638 "Out-of-order timestamp update detected" during a checkpoint
- Closed