When timestamp support was added to test/checkpoint in
WT-3181, some simplifying assumptions were made about timestamp management. In particular, the test periodically moves the oldest_timestamp to 100 ticks in the past of some active transaction. In addition, the timestamp chosen for checkpoints themselves is not coordinated with either commit timestamps or the specified oldest timestamp.
All of this means that test/checkpoint behaves as expected when updates commit close to the specified order, but if a running transaction falls more than 100 ticket behind current, the test is breaking the assumptions in WiredTiger's timestamp API.
For example, this is possible:
Two main tasks:
- make test/checkpoint use timestamps robustly – updating the oldest timestamp must wait for running transactions to complete, and commit timestamps cannot be in the past of a checkpoint timestamp; and
- WiredTiger's tests for "following the timestamp API rules" are not sufficiently robust: at least in diagnostic mode, we should see errors and/or assertion failures.