When a relational engine rolls back a transaction, the undo work itself is written to the transaction log as compensation log records. What problem do those records solve, and what happens if the server crashes again while a rollback is still in progress?

## Why undo has to be logged at all Rollback is not a metadata operation; it physically modifies pages: putting old values back, removing inserted tuples, reinserting deleted ones. Every page modification in a write-ahead-logged engine must be described in the log before the page can reach disk, otherwise recovery could neither reapply the modification nor even know it happened. So undo generates log records too. But what kind? Logging a reversal as an ordinary update would be a disaster: recovery would then consider that update part of the loser transaction and try to undo *it*, producing an endless alternation between doing and undoing. ARIES solves this with a distinct record type. ## What a compensation log record contains A CLR records that a specific earlier change has now been reversed. Two fields carry the weight: 1. **The redo information**: what the reversal did to the page, so redo can reapply it after a crash. Like any other change, the reversal may or may not have reached the data file. 2. **undoNext**: the LSN of the next log record belonging to the same transaction that still needs to be undone. This is copied from the prevLSN chain of the record that was just undone, effectively skipping over completed work. A CLR has **no undo information**, and that is the point. It is declared redo-only: recovery reapplies CLRs but never reverses them. ## The crash-during-rollback scenario, step by step Suppose transaction T made updates at LSNs 100, 110 and 120 and is being rolled back. - Undo reverses LSN 120 and writes CLR at LSN 200 with undoNext = 110. - Undo reverses LSN 110 and writes CLR at LSN 210 with undoNext = 100. - The server crashes before reversing LSN 100. On restart, analysis walks the log and finds T with no end record, so T is still a loser, and its last record is LSN 210. Redo repeats history, reapplying whatever is missing, including the two CLRs, so the pages reflect that 120 and 110 have been reversed. Undo then begins at T's last record, LSN 210, sees a CLR, and does not attempt any reversal for it; it simply follows undoNext to LSN 100, reverses that update, writes a final CLR, and writes T's end record. The result: each original update was reversed exactly once, across two crashes. ## Why exactly-once matters here Reversals are no more idempotent than the original changes. Undoing an insert removes a tuple; doing that twice can remove a different tuple that has since taken the slot. Undoing an update writes back a before-image; if a subsequent CLR-driven state has moved on, rewriting the old image can clobber correct data. Undoing a balance decrement adds the amount back; twice, and the account is wrong. The undoNext pointer chain is what enforces once-and-only-once. ## Termination and bounded work If CLRs could themselves be undone, a pathological loop is possible: crash, undo the undo, crash, undo that, forever, with the log growing each round. Making CLRs redo-only breaks the loop and gives a strict guarantee: the total undo work for a transaction is bounded by the number of its original updates, no matter how many times recovery is interrupted. Each crash strictly advances the rollback rather than restarting it. ## The same machinery serves ordinary rollback This is not recovery-only plumbing. A live ROLLBACK statement, a deadlock victim being aborted, a statement failing and rolling back to a savepoint: all walk the transaction's prevLSN chain backwards, apply reversals and write CLRs. Savepoints are simply a stopping point in that chain. Because normal aborts and crash recovery share the implementation, the recovery path is exercised constantly in production instead of only after failures. ## Operational consequences worth naming - **Rollback writes log.** A huge transaction that is aborted generates substantial additional log volume and I/O; rollback is not free and is not instantaneous. Aborting a bulk update can take as long as the update itself, occasionally longer. - **You cannot shorten rollback by killing the process.** Restarting only resumes the rollback from where the CLRs left off, and now with downtime added. - **Recovery time includes undo.** A crash that catches a long-running write transaction in flight extends the outage by the cost of reversing it, which is an argument for chunking bulk work into smaller transactions. ## One-line summary CLRs make rollback durable, resumable and non-repeating; being redo-only, they guarantee it terminates.