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

Fix history store panic when inserting an update without timestamp

    • Type: Icon: Build Failure Build Failure
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • WT10.0.0, 4.4.2, 4.8.0
    • Affects Version/s: None
    • Component/s: None
    • Labels:
      None
    • 5
    • Storage - Ra 2020-09-21, Storage - Ra 2020-10-05
    • v4.4

      (gdb) p hs_inserted
      $2 = true
      (gdb) p *list
      $3 = {ins = 0x7fa540cfcca0, ripcip = 0x0, onpage_upd = 0x7fa54636f240, restore = false}
      (gdb) p *list->onpage_upd
      $4 = {txnid = 149, durable_ts = 0, start_ts = 0, next = 0x7fa545f32380, size = 45, type = 3 '\003', prepare_state = 0 '\000', flags = 2 '\002',
        data = 0x7fa54636f267 "-"}
      (gdb) p *list->onpage_upd->next
      $5 = {txnid = 147, durable_ts = 6864857421328678914, start_ts = 6864857421328678914, next = 0x7fa54636fc60, size = 80, type = 3 '\003', prepare_state = 0 '\000',
        flags = 8 '\b', data = 0x7fa545f323a7 "P"}
      

      We have the code to handle mixed mode operation by marking the timestamped updates after it as obsolete.

      In WT-6585, we added a panic to ensure we are not reinserting anything again to the history store that may corrupt the history store data.

      However, the panic missed one valid edge case that handles mixed mode operation.

      Suppose there is the following update chain:

      U@0 -> U@20 -> U@0
      The mixed mode operation handling code will mark U@20 as obsolete. However, after we have inserted the oldest U@0 into history store which sets hs_inserted to true, we will trigger the following panic because U@20 is marked as obsolete in this case:

                  /* Skip updates that are already in the history store or are obsolete. */
                  if (F_ISSET(upd, WT_UPDATE_HS | WT_UPDATE_OBSOLETE)) {
                      if (hs_inserted)
                          WT_ERR_PANIC(session, WT_PANIC,
                            "Inserting updates older than obsolete updates or updates that are already "
                            "in the history store to the history store may corrupt the data.");
                      continue;
                  }
      

      However, in this case, it is actually valid to ignore that obsolete update.

            Assignee:
            chenhao.qu@mongodb.com Chenhao Qu
            Reporter:
            chenhao.qu@mongodb.com Chenhao Qu
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: