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

Fix test/checkpoint with timestamps

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 3.5.13, WT3.0.0
    • Affects Version/s: None
    • Component/s: None
    • None
    • Storage 2017-09-11

      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:

      ./t -T 3 -t m -s
      t: process 3057
          1: 1 workers, 3 tables
      checkpointer thread starting: tid: 3057:0x7ff6cee51700
      worker thread starting: tid: 3057:0x7ff6c7fff700
      Finished a checkpoint
      Finished verifying a checkpoint with 3 tables and 310 keys
      Finished a checkpoint
      Finished verifying a checkpoint with 3 tables and 2956 keys
      [1498184679:747492][3057:0x7ff6cee51700], t, WT_SESSION.checkpoint: read timestamp 13a8 older than oldest timestamp: Invalid argument
      t: session.checkpoint: Invalid argument
      Ran workers for: 0.203767 seconds
      Closing connection
      

      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.

            Assignee:
            sue.loverso@mongodb.com Susan LoVerso
            Reporter:
            michael.cahill@mongodb.com Michael Cahill (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: