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

Prepared transaction would wrongly trigger out of order timestamp handling

    • Type: Icon: Bug Bug
    • Resolution: Gone away
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Labels:
      None

                  /* If we've seen a smaller timestamp before, use that instead. */
                  if (min_insert_ts < upd->start_ts) {
                      /*
                       * Resolved prepared updates will lose their durable timestamp here. This is a
                       * wrinkle in our handling of out-of-order updates.
                       */
                      if (upd->start_ts != upd->durable_ts) {
                          WT_ASSERT(session, min_insert_ts < upd->durable_ts);
                          WT_STAT_CONN_DATA_INCR(session, cache_hs_order_lose_durable_timestamp);
                      }
                      __wt_verbose(session, WT_VERB_TIMESTAMP,
                        "fixing out-of-order updates during insertion; start_ts=%s, durable_start_ts=%s, "
                        "min_insert_ts=%s",
                        __wt_timestamp_to_string(upd->start_ts, ts_string[0]),
                        __wt_timestamp_to_string(upd->durable_ts, ts_string[1]),
                        __wt_timestamp_to_string(min_insert_ts, ts_string[2]));
                      upd->start_ts = upd->durable_ts = min_insert_ts;
                      WT_STAT_CONN_DATA_INCR(session, cache_hs_order_fixup_insert);
                  } else if (upd->start_ts != WT_TS_NONE)
                      /*
                       * Don't reset to WT_TS_NONE as we don't want to clear the timestamps for updates
                       * older than the update without timestamp.
                       */
                      min_insert_ts = upd->start_ts;
      

      To handle out of order timestamp, we will change the timestamps on the update chain. However, that should only be triggered for a committed update. If we write a prepared update to disk and its prepared timestamp is out of order, the current implementation will also trigger out of order timestamp handling, which is wrong as the prepared update can be aborted.

      This ticket is to fix this issue and write a test to ensure prepared updates should not trigger out of order timestamp handling.

            Assignee:
            backlog-server-storage-engines [DO NOT USE] Backlog - Storage Engines Team
            Reporter:
            chenhao.qu@mongodb.com Chenhao Qu
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: