Write-ahead logging records intent in an append-only log before dirty pages hit disk. PostgreSQL WAL, SQLite rollback journal's successor, and RocksDB WAL all follow this pattern so crash recovery can redo committed work and undo incomplete transactions.
WAL Record Shape
Each entry carries a type, transaction id, payload checksum, and length. Appends are sequential, matching SSD and HDD strengths.
c
Loading…
Checkpointing truncates replay time by flushing dirty pages first
Group commit batches multiple transactions per fsync
Log sequence numbers order recovery replay
Never mutate data pages before the WAL entry is durable
Working Through the Exercise
Keep the relevant documentation open while you implement. When your output disagrees with the reference, trace one failing case by hand before changing random lines.
Trace first: walk one failing input step by step
Read the manual: skim the official doc for the mechanism named in this task
Compare baselines: save measurements from the prior step so speedups are honest
Why for this exercise
You will append records to a WAL buffer and implement redo application on recovery. This exercise requires writing the log record before updating the in-memory page copy.
Write a C program that recovers 8 pages from a write-ahead log, using LSNs and checksums to decide what to replay.
Input (stdin):
First line: "checkpoint n": checkpoint is the highest LSN already flushed to the page files; n is the number of WAL records
Next n lines: "lsn page_id old_value new_value checksum"