Record the decision before changing the saved rows

The transaction introduction promised that a purchase succeeds or fails together. To see what storage must do, use two balances instead: A = 100 and B = 100. A transfer should produce A = 90 and B = 110. What if the machine stops after saving only A?

For this lesson, use a deliberately limited engine: one transaction at a time, tentative changes held privately in memory, and no unfinished transaction changes written to data pages. Assume valid log records can be distinguished from incomplete ones, and the storage system honors the persistence operations we request.

Save enough information to finish later

A log is an ordered record of changes and decisions. Rather than save A first and hope B follows, record both resulting values and a commit decision in the log. Make the necessary log records persistent before treating the transaction as committed.

Prepare privately
Transaction T plans A = 90 and B = 110. Saved data remains A = 100, B = 100.
Persist T's log records and commit decision
The durable description now contains both resulting values. Recovery has enough information to finish T.
Install the committed values
Update the data representation under exclusive access. Only then expose the new state to normal readers.

A durable description precedes the data changes it protects. The example serializes access so readers cannot see half of the installation.

Redo means applying a committed change again to bring data files up to date. Write-ahead logging, or WAL, requires the relevant log information to reach durable storage before changed data pages can reach it. A committed log can therefore protect data pages that have not all been saved yet.

Our model’s commit decision is recoverable before the final reply. The client may not receive a reply if the process stops afterward, but recovery must still recognize the transaction as committed. Client uncertainty does not erase that decision.

Explain why rollback is simple here

If T has no durable commit decision, recovery ignores its private changes. This works because the model never wrote those unfinished changes into data pages. Engines that allow such writes need a way to undo or otherwise hide them. The simpler assumption removes that responsibility from this first protocol, not from database engineering in general.

A real log also needs record framing, integrity checks, ordering, and a policy for damaged storage. A file of messages saying “updated A” is not enough if the engine cannot identify complete transactions reliably.

Stop after one data write

The commit record is durable. A’s page has been saved as 90. B’s page still says 100 when the process crashes. What must recovery do?

Use the decision, not the accidental page state

Recover the committed transaction’s full outcome: A = 90 and B = 110. The saved pages are an incomplete installation of a committed decision. Discarding T would contradict the durable commit record; accepting the mixed state would break the transfer’s atomicity.

The log bridges the gap between a logical commit and several physical writes. Next we make replay safe even when recovery itself is interrupted.

PostgreSQL’s WAL introduction states the write-ahead rule. The private-write, single-transaction protocol above is an educational model, not PostgreSQL’s complete recovery algorithm.

Extended reference

The extended chapter preserves the original technical coverage, additional examples, and citations. The explanation above supplies the concepts needed for this page; the reference develops the specialist cases.

Find a section from the original chapter