-
Type: Improvement
-
Resolution: Done
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
1
-
Joker - StorEng - 2023-10-17
There is a known gap in how WiredTiger enforces an API usage requirement related to timestamps and checkpoint.
When a user creates a checkpoint, they specify a timestamp at which all changes with timestamps less than or equal to that should be included, and no timestamp newer should be included.
WiredTiger checks that when a transaction starts committing, the timestamp chosen is valid compared to the stable timestamp. On the other hand, since WiredTiger does not co-ordinate transaction commit with checkpoint starting, a transaction that is in the process of committing may have a timestamp that should be included in a checkpoint, but not be included since the commit is still in progress while the checkpoint is running.
We should construct a test case that demonstrates that API issue.
I believe there is a nuance that might render this not possible. Since a checkpoint uses a pair of times, the timestamp and a transaction snapshot to determine what should be included. If the above race is present, the updates associated with a committing transaction will always be excluded based on the transaction ID check, and that would be the correct decision for checkpoint visibility.
Though it does indicate a bug in the application logic, and it would be nice to flag (somehow) that checkpoint didn't include an update the pure-timestamp version of time would have included.
- is depended on by
-
WT-9199 Checkpoint can miss transactions with commit times before stable
- Closed