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

Reconciliation incorrectly clears the transaction ids



    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Story Points:
    • Sprint:
      Storage Engines 2020-02-24


      When debugging WT-5595, sometimes I hit the assert:

               * We need to append a TOMBSTONE before the onpage value if the onpage value has a valid
               * stop pair.
               * Imagine a case we insert and delete a value respectively at timestamp 0 and 10, and later
               * insert it again at 20. We need the TOMBSTONE to tell us there is no value between 10 and
               * 20.
              if (unpack->stop_ts != WT_TS_MAX || unpack->stop_txn != WT_TXN_MAX) {
                  /* Timestamp should always be in descending order */
                  WT_ASSERT(session, upd->start_ts >= unpack->stop_ts);
                  WT_ERR(__wt_update_alloc(session, NULL, &tombstone, &size, WT_UPDATE_TOMBSTONE));
                  tombstone->txnid = unpack->stop_txn;
                  tombstone->start_ts = unpack->stop_ts;
                  tombstone->durable_ts = unpack->stop_ts;
                  tombstone->next = append;
                  total_size += size;

      The root cause is we incorrectly clear the transaction ids in a case. The sequence is as follow:

      We do update restore on the page and we don't write the disk image to disk. Thus the write gen of the page remains 0.

      We do reconciliation again on the page and we clear all the transaction ids as its write gen is smaller than the base write gen. This may be the root cause of many visibility and data mismatch problems we are seeing.


          Issue Links



              • Assignee:
                chenhao.qu Chenhao Qu
                chenhao.qu Chenhao Qu
              • Votes:
                0 Vote for this issue
                2 Start watching this issue


                • Created: