Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-7961

Sometimes lag oldest timestamp in timestamp_abort.

    • Type: Icon: Improvement Improvement
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • WT10.0.1, 4.4.9, 5.0.3, 5.1.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • Labels:
    • Storage Engines

      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:

      1. 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.
      2. Or instead of an option, every Nth iteration, do the above to lag the oldest timestamp.
      3. 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.

            sue.loverso@mongodb.com Susan LoVerso
            sue.loverso@mongodb.com Susan LoVerso
            0 Vote for this issue
            2 Start watching this issue