A PostgreSQL data page can be larger than the atomic write unit provided by storage. If the host fails while a page is being written, part of that page may reach durable storage while another part remains from an older version. Recovery cannot safely apply ordinary change records to a page whose internal structure may already be inconsistent.

full_page_writes addresses that failure mode. With the setting enabled, PostgreSQL records a complete image of a page in write-ahead log (WAL) on the first modification of that page after a checkpoint. During crash recovery, that image can replace a torn on-disk page before later WAL records are replayed.

The mechanism is tied closely to checkpoint boundaries. That connection affects both recovery safety and the amount of WAL a write-heavy system generates.

WAL normally records changes rather than whole pages

PostgreSQL WAL usually represents database changes more compactly than copying an entire data page for every modification. A record can describe the operation needed to move a page from one valid state to another.

That approach assumes recovery starts from a page that can be interpreted correctly. A partial page write breaks the assumption. Metadata, tuple data, line pointers, or other page regions may reflect different moments in time. Applying a normal WAL operation to such a mixture does not necessarily reconstruct a valid page.

A full page image gives recovery a complete replacement instead. The recovery process can restore the image from WAL and then apply subsequent records in order.

This protection is separate from the basic WAL rule that log records must become durable before the corresponding dirty data page is allowed to reach durable storage. Write-ahead ordering makes the recovery information available first; the page image makes that information sufficient even when the later data-page write is torn.

The first change after a checkpoint carries the image

PostgreSQL does not need to log a full copy for every update to the same page. With full_page_writes enabled, the first modification after a checkpoint causes the page image to be included in WAL. Later modifications to that page in the same checkpoint cycle can return to ordinary WAL records.

Consider one heap page modified several times:

checkpoint
    |
    +-- first update to page 42  -> full page image + change record
    |
    +-- second update to page 42 -> ordinary WAL
    |
    +-- third update to page 42  -> ordinary WAL

After the next checkpoint, page 42 becomes eligible for another full page image on its next modification.

The checkpoint establishes the recovery boundary that makes this sufficient. Crash recovery begins from a checkpoint and replays WAL forward. If a page write performed during that interval was interrupted, the first WAL record touching that page after the checkpoint can supply a complete image before later changes are applied.

This also means checkpoint frequency influences full-page-image volume. More frequent checkpoints create more opportunities for frequently modified pages to become first-touch pages again.

A torn page is different from a stale page

A stale page is internally valid but does not yet contain all durable changes. WAL replay is designed to advance such a page through the missing operations.

A torn page has a different problem: the page itself may contain pieces from different versions. Ordinary replay depends on valid page structure and therefore cannot treat arbitrary partial contents as a trustworthy starting point.

The distinction explains the role of the full page image. It is not primarily a faster form of replay and it is not a second copy of every write. It supplies a known complete page state at the point where ordinary change-oriented WAL can resume.

Data checksums can detect many forms of page corruption, including damage that produces a checksum mismatch, but detection alone does not provide the page contents needed for repair. Full page writes provide recovery material rather than merely an integrity signal.

Checkpoints can produce bursts of WAL volume

A checkpoint resets the first-change condition across pages. A workload that repeatedly modifies a broad working set can therefore emit many full page images soon after a checkpoint.

The effect depends on access patterns. A page changed once in a checkpoint cycle may carry one image. A hot page changed thousands of times in the same cycle still needs the image only on its first post-checkpoint modification, followed by ordinary WAL for later changes.

Shorter checkpoint intervals can increase the number of full page images generated over time because the same active pages cross the first-change boundary more often. Longer intervals can reduce that particular source of WAL, although checkpoint settings also affect recovery duration, dirty-page flushing, WAL retention pressure, and other operational behavior.

wal_compression can reduce the storage cost of full page images when compression is enabled. Compression changes the representation in WAL, not the recovery guarantee: replay decompresses the image before using it.

Full page writes protect a specific crash boundary

The setting is enabled by default because disabling it can leave recovery without enough information to repair a page that was only partly written during a system failure.

That guarantee has a precise scope. Full page writes do not replace fsync, storage ordering, WAL durability, backups, replication, or checksums. Each mechanism covers a different part of database durability or integrity.

They also do not imply that every PostgreSQL page is continuously copied into WAL. The extra image is associated with the first modification after a checkpoint, which limits the cost while preserving a complete recovery starting point for that checkpoint cycle.

Turning full_page_writes off is therefore not merely a WAL-volume tuning choice. It changes the assumptions PostgreSQL can make about recovering from partial data-page writes. A storage stack would need guarantees strong enough to make that failure mode irrelevant before the protection could be removed safely.

WAL volume and recovery safety share the same boundary

Full page writes connect a low-level storage constraint to a visible operational pattern. The possibility of partial page writes requires a complete recovery image, while checkpoint boundaries determine when PostgreSQL must record that image again.

As a result, elevated WAL generation after checkpoints is not incidental bookkeeping. It is the cost of establishing fresh page-level recovery material for the next checkpoint cycle. Tuning checkpoint cadence or WAL compression can change that cost, but the underlying requirement remains: recovery needs one complete page state before change-oriented WAL can safely continue.

PostgreSQL Database WAL Recovery Checkpoints