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

Remove the unstable historical versions at the end of rollback to stable

    • 8
    • Storage Engines - 2022-10-31, Storage Engines - 2022-11-14, 2023-04-04 Bibbidi-Bobbidi-Boo, 2023-04-18 Leviosa Not Leviosa, 2023-05-16 Chook-n-Nuts Farm, 2023-05-02 StorEng Bug Bash
    • v7.0, v6.0, v5.0, v4.4

      Rollback to stable missed to remove the historical versions that are written as part of the checkpoint reconciliation for the newly inserted keys when the rollback removes these keys to stable operation because of unstable updates.

      Not removing the unstable entries from the history store can lead to an WiredTiger assertion failure when these updates are reinserted as part of the oplog replay and moved to the history store again.

      Currently, as part of WT-9846 solution, we are fixing this issue to rely on the updates present in the update chain to remove the history store versions when none of them are found stable as part of the rollback to stable operation.

      The above-proposed solution is simple and has very minimal impact, but relying upon the update chain to decide whether to remove the history store versions doesn't sound good as in future we are going to aggressively remove the written updates that are written to the disk from the update chain, so instead of that solution, we want to go with the approach of scanning the history store table at the end of the rollback to stable operation to remove any unstable updates.

      Allowing rollback to stable to scan at the end in all the scenarios can uncover the scenarios that are not yet handled. As part of this ticket fix all those missing scenarios and remove the simple solution that is implemented as part of the WT-9846.

            etienne.petrel@mongodb.com Etienne Petrel
            haribabu.kommi@mongodb.com Haribabu Kommi
            Ruby Chen
            0 Vote for this issue
            12 Start watching this issue