WAL, checkpoints and torn pages: three different recovery guarantees

Commit the recovery information first

PostgreSQL's write-ahead rule requires the relevant log records to reach durable storage before the corresponding data-file changes. Recovery can replay the log, so a synchronous commit need not flush every modified data page. Group commit can share a log synchronization across transactions. [1]

The boundary is durable WAL, not merely a log buffer or a successful write into an operating system cache. PostgreSQL's reliability documentation follows the path through OS, controller and drive caches: recovery depends on those layers honoring persistence requests. [2]

A log position is not a persistence receipt

PostgreSQL distinguishes the insertion position, the write position and the durable flush position. pg_current_wal_lsn() reports the write position, not the flush position; pg_current_wal_flush_lsn() reports the latter. A WAL record can have an address while its bytes are still buffered. [8]

Keep the engine, timeline and progress stage with an LSN. Byte-distance between positions is not elapsed lag time, and the progress of one server does not establish that a standby has replayed the same record. [9] [8]

Three settings, three different questions

PostgreSQL 18 mechanisms, not recommended configuration changes.

These controls are not interchangeable. Asynchronous commit can lose recently acknowledged transactions while preserving consistent recovery, assuming the other safety mechanisms and storage work correctly. This differs from disabling synchronization. [3] [5]

With synchronous replication configured, acknowledgment may also depend on a standby. PostgreSQL distinguishes remote write, durable flush and replay; this article's simple commit explanation concerns local durability. [3]

A transaction is not a physical page write

A database page can span multiple storage write units. If interruption persists only part of the update, the page may mix old and new contents: a torn write. Neither the transaction's logical atomicity nor a device's sector size alone establishes whole-page atomicity. [2]

PostgreSQL's full-page images give recovery a page reconstruction basis. Ordinary change records alone may be insufficient. With full_page_writes enabled, the first modification after a checkpoint normally records an image. Other engines can use different defenses; this is not a universal storage-device guarantee. [3]

A checkpoint advances recovery progress

PostgreSQL flushes relevant dirty pages and records a checkpoint; crash recovery uses its associated redo position. More frequent checkpoints can reduce replay work but increase flushing and subsequent full-page-image traffic. Completion does not authorize arbitrary WAL deletion: archiving and replication can retain older segments. [4]

SQLite illustrates why engine names matter. Its WAL checkpoint transfers committed page content into the main database file; active readers can prevent completion. Do not read "checkpoint" as "all log files immediately disappear." [7, sections 2.1 and 2.2]

A real failure boundary: SQLite's WAL-reset race

SQLite documents a rare corruption race involving concurrent writes or checkpoints through multiple connections to one WAL-mode database. Version 3.51.3 fixes it; the documentation also lists backports 3.44.6 and 3.50.7. Check the actual embedded library build and its patch status, not merely whether WAL is enabled. This is a documented software defect, not a measured failure rate or evidence that WAL is generally unsafe. [7, section 11] [11]

The ARIES exception: checkpoint without a page flush

Mohan and colleagues' 1992 ARIES paper describes a fuzzy checkpoint that records transaction and dirty-page information without requiring dirty pages to be forced to storage. Therefore, "checkpoint" does not universally mean "flush every dirty page." [10, section 5.4]

ARIES redo can restore missing updates from uncommitted transactions before undo removes their effects. Its compensation records make rollback progress recoverable. This is a comparison with the original algorithm, not a claim that PostgreSQL or SQLite implements the same recovery protocol. [10, sections 3 and 6]

Recovery progress is not a recovery copy

Hesela's inference from these mechanisms: a checkpoint changes the existing database's recovery state; it does not create an independent copy that survives loss of that storage. PostgreSQL point-in-time recovery needs a physical base backup plus the required continuous WAL sequence. A logical pg_dump is not that physical base. [6]

For a recovery review, record the engine and version, acknowledgment mode, storage synchronization contract, page protection and retained recovery material separately. Test the supported recovery procedure on disposable resources. A healthy process restart alone does not establish behavior under power loss.

Related reading: failed fsync and durability and atomic rename and persistence ordering. Definitions: write-ahead log, database checkpoint, torn write and full-page write.

Primary sources and limits

Primary-source synthesis of PostgreSQL 18, SQLite documentation and selected recovery sections of the original ARIES paper; no database experiment or benchmark. Applies to the described logging protocols, not every database or storage device. Recovery depends on correct synchronization, retained recovery data and engine-specific configuration. No power-loss test, performance result or tuning recommendation is claimed.

1. PostgreSQL 18: Write-Ahead Logging
2. PostgreSQL 18: Reliability
3. PostgreSQL 18: WAL settings
4. PostgreSQL 18: WAL Configuration
5. PostgreSQL 18: Asynchronous Commit
6. PostgreSQL 18: Continuous Archiving and Point-in-Time Recovery
7. SQLite: Write-Ahead Logging (unversioned documentation)
8. PostgreSQL 18: Backup Control Functions, Table 9.97 and notes
9. PostgreSQL 18: WAL Internals
10. C. Mohan, Don Haderle, Bruce Lindsay, Hamid Pirahesh and Peter Schwarz. ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging. ACM TODS 17(1), 94-162 (1992), sections 3, 5.4 and 6.
11. SQLite 3.51.3 release notes: WAL-reset corruption fix (13 March 2026)

Sources reviewed 12 October 2026. PostgreSQL references are pinned to version 18.