Scenario 1

Suppose we have U@10 on the update chain at the start.

Eviction comes and writes U@10 to the data store.

Checkpoint starts at timestamp 20 and includes this page in the checkpoint.

We commit U@20 and U@30 to the key.

Eviction comes to the page and writes U@30 to the data store and U@20 to the history store.

Checkpoint checkpoints the history store.

Now we have U@10 in the data store and U@20 in the history store.

Since the version in the history store is newer than the version on the data store, rollback to stable will remove U@20 in this case. There is no issue.

Scenario 2
Suppose we have U1@20 on the update chain at the start.

Eviction comes and writes U1@20 to the data store.

Checkpoint starts at timestamp 20 and includes this page in the checkpoint.

We commit U2@20, U3@20, and U4@30 to the key.

Eviction comes to the page and writes U4@30 to the data store and U3@20, U2@20, U1@20 to the history store.

Checkpoint checkpoints the history store.

Now we have U1@20 in the data store and U3@20, U2@20, and U1@20 in the history store.

If we crash and restart, rollback to stable will only remove U3@20 from the history store and leave U2@20 and U1@20 intact, which is wrong.

This issue should be fixed if we enable checking transaction snapshot in rollback to stable for timestamped tables.