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

Reconciliation incorrectly clears the transaction ids

    XMLWordPrintable

    Details

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

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: