Recovery has two different jobs
- No-force: committed data may be missing from disk → redo.
- Steal: uncommitted data may be present on disk → undo.
Durable WAL must precede the corresponding page write.
1 / 8
Durable WAL must precede the corresponding page write.
A high pageLSN does not prove the transaction committed.
Persisted page: x=7, y=0, LSN=5.
| LSN | Transaction | Update or outcome |
|---|---|---|
| 2 | T1 | x: 0 → 4 |
| 3 | T1 | commit |
| 5 | T2 | x: 4 → 7 |
| 6 | T2 | x: 7 → 9 |
| 8 | T3 | y: 0 → 6 |
| 9 | T3 | commit |
Which transactions win? Which updates redo? Which updates undo?
The toy output pageLSN is 5. Its simplified undo rule is not a production page-history convention.
Loser writes: 4 → 7 → 9.
9 → 7 → 4.9 → 4 → 7 — wrong final value.Each before-image reverses one update, not the whole transaction.
T1 commits x=4
T2 writes x=9, then aborts to x=4
T3 commits x=12
crash
Undoing every historical noncommitter would restore 4 over 12.
What durable fact is missing?
The standalone exercise is one recovery pass. The capstone adds completed rollback history and keeps recovery calls atomic.
Explain why an already-persisted loser skips redo but still requires undo.