Right now test/csuite/timestamp_abort always sets both the oldest timestamp and stable timestamp to the save value, which is the value returned from query_timestamp("get=all_durable").
It would be useful to add an option to test the typical usage case where the oldest timestamp lags the stable timestamp by a bit.
There are several ways to do this:
- Have an option so that for the entire duration of the test the oldest lags stable. An easy implementation would be to have, for iteration N of the loop in thread_ts_run, that oldest be set to the stable value of iteration N-1.
- Or instead of an option, every Nth iteration, do the above to lag the oldest timestamp.
- Or, decide this isn't actually a useful feature because the test itself does not do any reads while the child process runs (but the library code does do different code paths I think).
It isn't clear to me how much more testing coverage we'd get by adding an option to always lag versus no option but lagging once in a while unconditionally.