WAL and Atomicity
Fast recall
Quick revision
Core answer
Understanding the log-before-data rule and the fact that redo, undo, and MVCC recovery responsibilities differ between storage engines.
Claiming that every WAL record stores both an old and new value, or that PostgreSQL and InnoDB use identical redo and undo designs.
Contrast PostgreSQL's redo-oriented WAL and MVCC visibility with InnoDB's redo log plus separate undo logs.
Interview-ready guide
Interview answer
Write-ahead logging follows one core ordering rule: the recovery information for a change must be written before the related data page can be flushed.
A durable commit record and transaction status then let recovery identify the outcome. The exact mechanism is engine-specific. PostgreSQL uses redo-oriented WAL with MVCC row versions and transaction status, so incomplete versions remain invisible.
InnoDB uses a redo log for crash recovery and separate undo logs for rollback and consistent reads. It is therefore wrong to claim that every WAL record contains both old and new values. Logging supports durability and the overall atomic recovery design, while the engine's transaction and visibility rules ensure that users never observe a partly committed transaction.
Commit I/O also depends on synchronous settings and group commit, not a universal one-fsync-per-transaction rule.
WAL and Atomicity
Direct Answer
Many databases combine transaction state with write-ahead or redo logging so recovery can keep committed work and discard incomplete work. The exact mechanism is engine-specific: some systems use separate undo information or MVCC rather than storing old and new values in one WAL record. The shared rule is that recovery must never expose a partly committed transaction.
Code Example
Shared log-before-data rule
1. Create an engine-specific recovery record for a page change.
2. Give the record a log position and write it before that dirty page can be flushed.
3. Record transaction commit according to the configured durability policy.
4. After a crash, replay the durable records needed to restore pages.
5. Use transaction status, MVCC visibility, or separate undo data so incomplete work is not exposed.
PostgreSQL: redo-oriented WAL + MVCC/transaction status
InnoDB: redo log + separate undo logs
This is a model of the ordering rule, not executable Java and not a claim that all engines store the same fields.
Common Mistakes & Pitfalls
- Combining redo and undo into one universal log: InnoDB has redo and separate undo logs; PostgreSQL WAL recovery is redo-oriented and relies on MVCC visibility for incomplete transactions.
- Saying WAL alone is atomicity: Atomicity comes from the engine's transaction, visibility, logging, and recovery rules working together.
- Assuming one flush per commit: Group commit and durability settings change the physical I/O path.
Check your understanding
Answer these without looking back at the article.
- What is the difference between a synchronous and asynchronous WAL?
- How does WAL also support replication in PostgreSQL?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.