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

Fix rollback to stable not rollback transaction at snapmax

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

      In rollback to stable we rollback transactions that are not visible in regards to checkpoint's recorded snapshot.

      Here's the logic we check against snap max in that code. The implementation says that only transaction id is larger than snapmax is not visible.

          /*
           * Snapshot data:
           *	ids < recovery_ckpt_snap_min are committed,
           *	ids > recovery_ckpt_snap_max are non committed,
           *	everything else is committed unless it is found in the recovery_ckpt_snapshot array.
           */
          if (txnid < conn->recovery_ckpt_snap_min)
              return (false);
          else if (txnid > conn->recovery_ckpt_snap_max)
              return (true);
      

      However, in the normal transaction visibility check:

          /*
           * WT_ISO_SNAPSHOT, WT_ISO_READ_COMMITTED: the ID is visible if it is not the result of a
           * concurrent transaction, that is, if was committed before the snapshot was taken.
           *
           * The order here is important: anything newer than the maximum ID we saw when taking the
           * snapshot should be invisible, even if the snapshot is empty.
           */
          if (WT_TXNID_LE(txn->snap_max, id))
              return (false);
      

      The transaction is also considered not visible if it's at snap max.

      This inconsistency results rollback to stable not rolling back the transaction at snapmax during recovery.

            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:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: