-
Type: Technical Debt
-
Resolution: Done
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
8
-
Storage - Ra 2021-10-18, Storage - Ra 2021-11-01
-
v5.1
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.
- is depended on by
-
WT-8277 Change salvage to resolve prepared records.
- Backlog
-
WT-8278 Change salvage to remove history store records
- Backlog
-
WT-8279 Change salvage to merge history store records after salvage completes
- Backlog
- is related to
-
WT-7507 Update salvage for a history store and timestamp world
- Closed