In the following sequence, RTS doesn't fix the corrupted non-timestamped table.

1. When a checkpoint is running with a snapshot (min-1000, max-1001), a new transaction with id (1005) has written some updates to the table (t1) and those updates are written to the disk by eviction before checkpoint operation checkpoint this table (t1). The transaction id (1005) updates are also to be part of the checkpoint.

2. Corrupt the table (t1)

2. During restart, RTS ignores the table (t1) as it has some corruption.

3. After successful recovery, the latest checkpoint is written using the new snapshot (min-4, max-4).

4. Perform the salvage operation to fix the table (t1)

5. Performing RTS on the table (t1) after salvage either as part of salvage or restart the database doesn't remove the transaction id (1005) updates from the table(t1) as the transaction id on the table is reset after a successful recovery.