WiredTiger internally uses the pinned timestamp to decide whether a key/value is globally visible or obsolete by comparing the durable start/stop timestamp along with the transaction id.

The pinned timestamp gets updated in many code flows. Rollback to stable module also uses this pinned timestamp to decide whether the historical version is obsolete or not before restoring it.

As part of the recovery process, the oldest and the stable timestamps are retrieved from the checkpoint and set, but the pinned timestamp is not set explicitly. As part of the RTS operation, it retrieves the pinned timestamp as 0 and restores a wrong obsolete version as stable data. This is possible only when the history store has out-of-order updates where the stable update is first in the key range and the obsolete updates are the last in the range.

The solution to this problem is to explicitly update the pinned timestamp whenever the oldest timestamp is updated as part of the recovery.