Database checkpoints work by establishing a durable recovery boundary between older work that is already represented safely in data files and newer work that may still need WAL replay after a crash. A checkpoint does not mean the entire database stops changing; it means the engine completes a defined set of dirty-page obligations and records enough metadata to tell recovery where redo can begin.
This pillar explains dirty pages, checkpoint start and completion, redo positions, full-page writes, write spreading, checkpoint frequency, WAL retention, restartpoints, I/O bursts, storage headroom, backup interactions and why forcing checkpoints too often can make a healthy database slower.
Master guide: How Write-Ahead Logging Works · Related: How MVCC Works · How X Works Hub
The Direct Answer: A Checkpoint Narrows the Recovery Window
Older Changes Become Part of the Durable Data Baseline
A checkpoint drives required dirty data pages toward durable storage so recovery does not need to reconstruct the entire database history from WAL. The database records a checkpoint and a redo position from which crash recovery can safely begin.
Newer Changes Continue to Accumulate
Transactions keep running and producing WAL. The checkpoint therefore does not freeze time. It establishes a boundary saying that changes older than the redo requirement are already represented in the data files according to the engine’s recovery rules.
Dirty Pages Explain Why Checkpoints Exist
Committed Work Can Remain Only in Memory Plus WAL
A transaction can be durable because its WAL is flushed while its modified table and index pages remain dirty in the buffer pool.
Someone Must Eventually Write Those Pages
Background writers and checkpoints gradually make data files catch up with the durable history. Without page writeback, memory pressure grows and recovery would need to replay an increasingly long log.
Checkpoint Start and Checkpoint Completion Are Different Moments
The Engine Chooses a Recovery Horizon
At the start, it identifies the WAL and dirty-page state relevant to the checkpoint.
Page Writes Can Continue for Some Time
Modern systems deliberately spread checkpoint I/O instead of flushing everything in one burst. The checkpoint completes only after its defined data-page and metadata conditions have been satisfied.
The Redo Position Is More Important Than the Wall Clock
Crash Recovery Needs a WAL Address
PostgreSQL records a redo point associated with checkpoint metadata. Recovery scans forward from that location because earlier required page changes are guaranteed to be present in data files.
A Timestamp Alone Cannot Prove Storage State
The checkpoint can overlap ordinary transaction activity, and page writes complete at different times. Recovery therefore uses explicit WAL positions and control metadata rather than simply asking when the checkpoint finished.
Checkpoints Do Not Flush Every Possible Byte in the Same Sense
They Flush the Dirty State Required by the Engine’s Rule
The exact page sets and ordering belong to the implementation.
Other Caches and Storage Layers Still Exist
Database buffers, operating-system page cache and device caches have different durability roles. A checkpoint protocol must cross the durability boundaries promised by the database rather than merely copy bytes from one RAM layer to another.
PostgreSQL’s Concrete Checkpoint Rule
Dirty Heap and Index Pages Are Written
PostgreSQL 18’s current WAL configuration documentation states that checkpoints guarantee heap and index data files are updated with information written before the checkpoint’s redo boundary.
A Checkpoint Record Is Written to WAL
Recovery then finds the latest checkpoint and starts REDO from the redo record identified there. PostgreSQL can recycle or remove older WAL segments when no other retention requirement still needs them.
Frequent Checkpoints Shorten Crash Recovery
Less Post-Checkpoint WAL Needs Replay
A newer durable baseline means fewer changes to redo after failure, all else equal.
Recovery-Time Objectives Can Motivate Shorter Intervals
Systems that must restart quickly may accept more steady-state checkpoint work. The best cadence depends on workload, WAL generation, storage bandwidth and acceptable restart time.
Frequent Checkpoints Increase Steady-State I/O
Dirty Pages Are Forced Out More Often
That consumes storage bandwidth which foreground reads and writes also need.
The Same Page Can Be Written Repeatedly Across Checkpoints
A hot page modified continuously may be flushed in each checkpoint cycle. Longer intervals can let multiple in-memory changes collapse into fewer data-page writes, though they enlarge recovery work and WAL retention.
Full-Page Writes Couple Checkpoint Frequency to WAL Volume
The First Page Modification After a Checkpoint Can Log a Full Image
PostgreSQL uses this mechanism by default to protect against torn-page risk.
More Checkpoints Mean More First Modifications
A very short checkpoint interval can therefore increase WAL volume because hot pages repeatedly cross the ‘first change after checkpoint’ boundary. PostgreSQL explicitly documents this trade-off.
Why Page Images Help After a Torn Write
A Crash Can Leave a Partially Updated Page
Storage might contain only part of a page’s new contents.
A Full-Page Image Restores a Known Consistent Base
Recovery can replace the damaged page image using WAL and then replay later changes. Other databases can use doublewrite buffers, checksums or atomic-write technologies instead; the objective is the same: recovery must not build on a torn base.
Checkpoint I/O Should Be Smoothed
One Giant Flush Causes Latency Spikes
If thousands of dirty buffers are written in a short burst, foreground requests compete with checkpoint writes.
PostgreSQL Spreads Checkpoint Work
Its checkpoint_completion_target controls how checkpoint page writes are distributed over much of the interval. This trades a smoother I/O profile against retaining a longer recovery horizon while the checkpoint remains in progress.
Checkpoint Timeout and WAL Volume Are Two Different Triggers
Time Can Trigger a New Checkpoint
PostgreSQL begins checkpoints based on checkpoint_timeout.
WAL Growth Can Trigger One Earlier
Approaching max_wal_size can request a checkpoint even when the timer has not expired. A write-heavy workload can therefore checkpoint more often than the nominal time interval suggests.
max_wal_size Is Not a Hard Storage Cap
Checkpoint Pressure Uses It as a Target
Crossing the threshold influences checkpoint scheduling.
Retention Can Override It
Archiving, replication slots, standbys and recovery needs can keep WAL segments beyond the ordinary size target. PostgreSQL’s documentation warns that max_wal_size is not a hard limit and recommends disk headroom.
Checkpoints and WAL Recycling Are Related but Not Identical
A Checkpoint Can Make Older WAL Unnecessary for Local Crash Recovery
Once earlier changes are durable in data files, local redo no longer needs those segments.
Other Consumers May Still Need Them
Archived recovery, standbys, backup operations, replication slots or WAL summarisation can retain them. Deleting WAL purely because a checkpoint completed can break another subsystem.
Restartpoints Are the Recovery-Side Relative of Checkpoints
A Standby Replaying WAL Cannot Create Arbitrary Checkpoints
Its safe restart positions depend on checkpoint records generated on the primary.
Restartpoints Persist Recovered State
PostgreSQL documents restartpoints during archive recovery or standby operation. They reduce future restart work on the recovering server while respecting the checkpoint history embedded in the WAL stream.
The Root Cause of a Checkpoint Warning Matters
Repeated Requested Checkpoints Can Signal Too Little WAL Headroom
Bulk loading can generate WAL faster than max_wal_size expects.
The Correct Fix Is Not Always ‘Increase the Timeout’
Inspect whether checkpoints are time-triggered or WAL-triggered, measure storage bandwidth and recovery requirements, then adjust the parameter responsible for the observed pressure.
A Checkpoint Is Not a Transaction Commit
Transactions Commit Continuously Between Checkpoints
Durability is provided by WAL flushes under the configured commit mode.
The Checkpoint Is a Storage-Maintenance Milestone
It advances the durable data-file baseline. Waiting for a checkpoint at every commit would destroy one of WAL’s main performance advantages.
A Checkpoint Is Not a Backup Either
It Helps Create a Cleaner Recovery Baseline
A filesystem-level snapshot taken after a checkpoint can have less WAL to replay.
But It Does Not Create an Independent Copy
Loss of the data directory after the checkpoint still requires a backup or replica. PostgreSQL’s backup documentation notes that physical snapshot backups may replay WAL on startup and suggests a checkpoint beforehand only to reduce recovery time, not to replace backup procedures.
Checkpointing and Memory Pressure Interact
Dirty Buffers Occupy the Buffer Pool
If writeback cannot keep pace, useful cache space can be dominated by dirty pages waiting for storage.
Background Writers Can Reduce Checkpoint Bursts
Engines often write dirty pages between checkpoints so the checkpoint is not the only mechanism draining memory. Checkpoint tuning should therefore be evaluated with the normal background-write path, not in isolation.
The Checkpoint Can Affect Tail Latency More Than Average Throughput
Most Requests May Remain Fast
An I/O burst affects only some transactions.
Percentiles Reveal the Spike
Monitor p95, p99 or maximum latency around checkpoint periods. A system with acceptable average throughput can still violate user-facing latency goals because checkpoint writes saturate storage intermittently.
Storage Technology Changes the Best Cadence
Rotating Disks, SSDs and Network Volumes Behave Differently
Random write cost, fsync latency, queue depth and internal caches vary widely.
Do Not Copy Another Server’s Timing Values Blindly
PostgreSQL’s defaults are starting points. Representative workload tests and pg_stat_checkpointer/pg_stat_io data should guide tuning on the actual hardware.
Checkpointing After Bulk Load
Large Imports Dirty Many Pages and Generate WAL
They can push max_wal_size and cause repeated requested checkpoints.
A Larger WAL Budget Can Reduce Mid-Load Checkpoint Frequency
But it increases possible recovery work and disk use. The right setting depends on whether the bulk workload is occasional, whether restart time matters during the load and whether storage headroom is available.
Checkpointing and Index Builds
Index Creation Touches Many Pages
The write path can create large dirty-page populations and WAL depending on the operation and engine settings.
Maintenance Windows Need I/O Budget
A checkpoint overlapping a heavy build can intensify write traffic. Scheduling and checkpoint parameters should account for planned maintenance rather than assuming foreground OLTP is the only source of dirty pages.
Recovery Time Is Not Simply ‘WAL Since the Last Checkpoint’ in Seconds
Replay Cost Depends on Bytes and Page Access
A quiet ten-minute interval can produce less recovery work than a busy one-minute interval.
Hardware and Cache State Matter
Recovery can be CPU-bound, storage-bound or limited by random page reads. Use actual WAL volume and recovery measurements rather than only checkpoint wall-clock spacing.
Checkpoints and Page Checksums Solve Different Problems
Checkpoint Makes Data Durable Enough for Recovery Baselines
It controls when page state reaches storage.
Checksums Detect Certain Corruption
They help reveal unexpected byte damage but do not themselves reconstruct missing committed work. WAL recovery and checksums complement each other rather than substitute for one another.
Checkpoints and fsync Are Different Layers
Checkpoint Schedules What Must Be Persisted
It determines a set of dirty data pages and associated metadata work.
fsync-Style Operations Cross the Durability Boundary
The operating-system and storage stack must actually make the written data durable. A checkpoint that merely issues buffered writes but never ensures required persistence would not satisfy the recovery contract.
Checkpoint Completion Must Be Crash-Safe
Control Metadata Identifies the Recovery Starting Point
If that metadata claimed a later safe point before required pages were durable, recovery could skip changes it still needed.
Publication Comes After the Necessary Work
The checkpoint protocol therefore orders page persistence, WAL checkpoint records and control metadata carefully. The exact sequence is engine-specific, but the invariant is universal: never advertise a recovery boundary the storage state cannot support.
Common Failure: Forcing CHECKPOINT After Every Critical Transaction
Why It Seems Reassuring
The operator wants the data pages themselves on disk immediately.
Why It Defeats WAL’s Design
A synchronous WAL commit already provides durability under the database’s contract. Frequent forced checkpoints add page-write work, increase WAL image traffic and can hurt concurrency without making the logical transaction ‘more committed’ in the ordinary sense.
Common Failure: Treating max_wal_size as Disk Quota Enforcement
The Database Can Exceed It
Retention needs and bursts can keep more WAL.
Disk Monitoring Is Still Required
Capacity alerts should watch actual pg_wal usage and the reasons segments are retained. Configuration targets do not replace filesystem headroom.
Common Failure: Tuning for Fast Recovery and Ignoring Steady-State Latency
Very Frequent Checkpoints Look Good in a Restart Test
Less WAL is replayed.
But Production Users Pay the Continuous I/O Cost
Measure both recovery time and normal p99 latency. Reliability tuning is an optimisation across failure recovery and everyday service quality.
Common Failure: Tuning for Smooth Foreground Traffic and Ignoring Recovery Time
Long Intervals Reduce Some Checkpoint Pressure
Dirty pages can be written more gradually.
A Crash Can Require More Redo
If the system has a strict recovery-time objective, a very large WAL horizon can be unacceptable. Recovery objectives need to be explicit, not discovered during the first real failure.
A Practical Checkpoint Experiment
Use a Disposable Database
Run a sustained write workload and record checkpoint counts, requested versus timed checkpoints, WAL generation, dirty-page I/O and latency.
Change One Parameter at a Time
Adjust max_wal_size or checkpoint_timeout within safe test limits and rerun the same workload. Compare checkpoint spacing, p95/p99 latency, WAL volume and recovery duration. Do not infer causality from a production graph where several settings changed simultaneously.
A Crash-Recovery Experiment Around Checkpoints
Create Known Committed State Before and After a Checkpoint
Force or wait for a checkpoint, then continue writing.
Crash During the Later Interval
On restart, verify all commits that satisfied the durability contract, measure redo duration and inspect recovery logs. Repeat with different WAL volumes after the checkpoint. The experiment shows what the recovery boundary actually buys.
Rainbolt View: A Checkpoint Is a Mile Marker on a Road of Receipts
Everything Before the Marker Has Reached the Warehouse Shelves
Recovery does not need to reconstruct those earlier shelf moves from receipts.
Everything After the Marker May Still Need the Receipts
The warehouse keeps the later receipts until the next safe marker advances. The checkpoint does not stop the trucks; it gives recovery a trustworthy place to start.
CivDJ View: Checkpoints Convert Accumulated Promise Into Material State
WAL Is a Durable Narrative of Decisions
The database can commit quickly by recording those decisions.
Checkpointing Turns Narrative Into Baseline Infrastructure
It gradually makes table and index files embody those decisions directly. Recovery then needs only the portion of the narrative not yet materialised at the checkpoint boundary.
Frequently Asked Questions
Does a Checkpoint Commit Open Transactions?
No. Transaction commit decisions are separate. A checkpoint writes database pages and recovery metadata according to engine rules; it does not force every active transaction to commit.
Does a Checkpoint Block All Queries?
Modern engines are designed to continue serving work. The checkpoint can still consume I/O and affect latency, but it is not conceptually a global pause of the database.
More Frequently Asked Questions
Why Does WAL Grow After a Checkpoint?
New transactions continue producing log records, and full-page-write mechanisms can add extra WAL for first page modifications after the checkpoint.
Can I Delete WAL Before the Last Checkpoint?
Only the database should manage WAL lifecycle. Archiving, replication or backup obligations can require segments that local crash recovery no longer needs. Manual deletion risks unrecoverable damage.
The Pillar Boundary and Sources
What This Article Owns
This pillar owns checkpoint-specific mechanics: dirty-page baselines, redo positions, checkpoint cadence, full-page-write interaction, WAL retention and restartpoints. Group commit and restart replay have separate owners.
Sources and Further Reading
The concrete reference is PostgreSQL 18’s WAL Configuration, which documents checkpoint triggers, redo positions, dirty-page flushing, checkpoint_completion_target and restartpoints. The WAL Internals page explains recovery starting from checkpoint metadata.
Final Synthesis: A Checkpoint Is a Promise About How Far the Data Files Have Caught Up
The Mechanism
Write required dirty pages, persist checkpoint metadata and establish a redo position that recovery can trust.
The Trade-Off
More frequent checkpoints reduce replay distance but consume more steady-state I/O and can increase WAL volume. Less frequent checkpoints reduce repeated writeback but increase recovery work and WAL retention. Good tuning makes that trade explicit rather than pretending one extreme is free.
Worked Checkpoint Timeline: Pages Written While Transactions Continue
Imagine a checkpoint begins at WAL position 5000. At that moment, pages A, B and C are dirty. While the checkpoint writes them, new transactions modify pages D and E and generate WAL positions beyond 5000. The checkpoint is not a frozen photograph of the whole database. It is a protocol that ensures the data-file state becomes sufficient for recovery from a particular redo boundary while newer work continues.
This explains why checkpoint reasoning must use WAL positions and dirty-page state rather than one timestamp. Pages written during the checkpoint can have different latest modifications. The engine tracks enough information to identify which changes are guaranteed durable in data files and which must remain recoverable from WAL.
Checkpoint Completion Is a Publication Event
The engine should not advertise a newer recovery baseline until the required page writes and durability operations have completed. If control metadata jumped ahead early, crash recovery could start after a change that still existed only in an unwritten dirty page.
Checkpoint completion therefore resembles other safe handoffs in storage systems: prepare the replacement or baseline, make its prerequisites durable, then publish the metadata that tells future readers or recovery code to rely on it. The same general pattern appears in LSM manifest updates and copy-on-write root switches.
Dirty-Page Age Matters
Two dirty pages can have very different recovery significance. One may have been dirtied long before the checkpoint and still not written. Another may have become dirty moments ago. The oldest relevant WAL position among dirty pages helps determine how far back recovery might need to begin under many recovery designs.
This is why a database cannot simply say “the latest checkpoint is at LSN X, therefore nothing before X matters” without respecting the checkpoint’s own redo calculation. The recovery boundary must account for pages whose first unpersisted changes began earlier.
Checkpoint Pressure and Background Writeback
A healthy buffer manager usually writes some dirty pages before the checkpoint is forced to deal with them. If background writeback keeps pace, the checkpoint has less work to do and is less likely to create an I/O cliff.
If background writeback falls behind, each checkpoint inherits a larger dirty set. That can produce bursts, longer checkpoint duration and greater overlap with the next checkpoint cycle. Tuning therefore involves the whole writeback pipeline, not only checkpoint_timeout.
Checkpoint Frequency and Hot Pages
Consider one index root page modified thousands of times per minute. If checkpoints occur very frequently, that page may be written repeatedly even though later modifications quickly make the freshly written version obsolete in memory.
A longer interval can let many in-memory changes collapse into fewer data-page writes. But the trade is more WAL to retain and potentially more redo after a crash. Hot-page workloads therefore make the checkpoint cadence especially visible in write amplification.
Checkpoint Frequency and Cold Pages
Cold pages behave differently. Once written, they may stay clean for a long time. Frequent checkpoints do not repeatedly rewrite them unless they are modified again. The workload’s temporal locality therefore matters when predicting checkpoint I/O.
Two databases with the same write throughput can have different checkpoint costs if one concentrates changes on a small hot set and the other spreads them across a large working set. Measure dirty-page churn, not only total transactions per second.
Why Full-Page Writes Spike After Checkpoints
With PostgreSQL’s default full_page_writes enabled, the first modification of a page after a checkpoint can log a full image. A busy working set therefore creates a wave of full-page images soon after each checkpoint.
This can make WAL generation appear bursty even when application write volume is steady. Operators who see WAL rate increase after shortening checkpoint intervals should check whether more frequent first-after-checkpoint page images explain the change before blaming application traffic.
Checkpoint Tuning Needs an RTO Budget
Suppose the service requirement says crash recovery must normally complete within two minutes. Measure actual replay throughput on production-like hardware, then estimate how much WAL can be replayed within that window. That gives a practical upper bound on the amount of post-checkpoint recovery work the system should usually accumulate.
This is more useful than choosing checkpoint_timeout by folklore. If recovery can replay 4 GB per minute under representative conditions, a two-minute RTO suggests a very different acceptable WAL horizon than a system that replays 200 MB per minute.
Checkpoint Tuning Also Needs a Foreground-Latency Budget
The database cannot spend every available I/O resource on making restart fast if normal requests must meet strict p99 latency. Spread checkpoint writes, limit storage saturation and observe whether foreground fsync or reads slow while checkpoints run.
Good tuning is therefore a two-objective problem: keep recovery work bounded and keep steady-state I/O smooth. An ideal checkpoint interval in one dimension can be poor in the other.
Checkpoint and WAL Storage Should Be Monitored Together
If checkpoints occur less often, more WAL may remain relevant for local recovery. If archiving or replication also lags, additional historical WAL remains pinned. Disk growth can therefore combine several independent causes.
A useful dashboard separates WAL generated, WAL recycled, WAL retained for checkpoints, WAL retained for archive, and WAL retained for replication consumers where the engine exposes those categories. One total directory-size graph is not enough to diagnose the mechanism.
Forced Checkpoints Are Operational Tools, Not Routine Commit Primitives
There are legitimate reasons to request a checkpoint: testing recovery, preparing certain maintenance operations, reducing replay work before a controlled snapshot, or responding to administrative needs.
Using CHECKPOINT as part of every application transaction is a different matter. It converts a carefully amortised background process into foreground work and can multiply full-page WAL. Application durability should normally rely on transaction commit semantics, not forced checkpointing.
Restartpoints Show the Same Principle During Recovery
A standby or archive-recovery server also wants to avoid starting from the beginning of its replayed history after another interruption. Restartpoints persist enough recovered state to advance the future recovery baseline.
They can only be established at safe checkpoint-related positions present in the WAL stream. This restriction shows that recovery baselines are part of a globally ordered protocol, not arbitrary local snapshots the standby can invent whenever convenient.
Checkpoint Metrics Should Be Read Causally
A rise in requested checkpoints can indicate WAL generation pressing against max_wal_size. A rise in timed checkpoints with low dirty-page volume can indicate a mostly idle system. Long checkpoint write duration can indicate storage pressure or an oversized dirty set.
Each symptom suggests a different next question. Treating every checkpoint count as ‘too many checkpoints’ loses the reason the engine created them.
A Practical Post-Change Verification
After changing checkpoint settings, compare at least one full workload cycle before and after. Record checkpoint frequency, WAL volume, data-page writes, p95/p99 latency, fsync latency, recovery time from a controlled crash and actual pg_wal disk usage.
A configuration that lowers checkpoint count but causes WAL retention to threaten disk capacity is not clearly better. Neither is one that shortens recovery while doubling user-facing tail latency. Keep the decision tied to explicit service goals.
Checkpoint Worked Example: Same Transaction Rate, Different Recovery Cost
Consider two one-hour workloads that both commit 100,000 transactions. Workload A updates the same small set of hot pages repeatedly and generates 2 GB of WAL. Workload B spreads changes across a much larger working set and generates 10 GB of WAL. Transaction count is identical, but checkpoint write volume, full-page images and recovery work can differ dramatically.
This is why checkpoint planning should use WAL bytes, dirty-page churn and measured replay speed rather than transaction count alone. The storage engine pays for physical change, not for the application’s abstract idea of one transaction.
Checkpoint Cadence and Buffer-Pool Residency
Writing a dirty page does not necessarily evict it from the buffer pool. The page can remain cached as a clean page and be modified again later. Checkpointing therefore changes durability state without necessarily changing read-cache residency.
This distinction matters when diagnosing a drop in cache hit rate. A checkpoint can create storage traffic while the same hot pages remain resident. Conversely, memory pressure can evict clean pages independently of checkpoint activity. Do not use one metric as a proxy for the other.
Checkpoint Completion and WAL Archiving
A local checkpoint can make older WAL unnecessary for local crash recovery, but archive policy can still require those segments to be copied elsewhere before recycling. A checkpoint therefore advances one retention boundary while the archive system controls another.
If archiving falls behind, pg_wal can grow even while checkpoints complete normally. Operators should inspect archive status before increasing checkpoint frequency; the bottleneck can sit entirely outside the checkpoint mechanism.
Checkpoint Completion and Replication Slots
A physical or logical replication consumer can pin WAL older than the latest checkpoint. The checkpoint does not override that consumer’s required position.
This makes WAL storage a shared dependency among recovery and replication. Capacity planning should ask which subsystem owns the oldest required LSN. The answer can change over time as replicas disconnect or slots stop advancing.
Checkpoint Review: What Good Looks Like
A healthy checkpoint regime usually shows predictable cadence, manageable dirty-page writeback, limited surprise in p99 latency, enough WAL headroom for bursts and a measured crash-recovery time within the service objective. No single parameter proves health.
The review should be repeated after workload changes. A configuration that suited a 100 GB database can behave differently after the working set, index count or transaction mix doubles. Checkpoint tuning is operational, not once-and-for-all mathematics.
Checkpoint Capacity Planning: Leave Room for the Transition
A checkpoint does not instantly replace dirty memory with free space. While pages are being written, transactions continue producing new WAL and can dirty the same or different pages again. Storage bandwidth therefore serves a moving target. A system operating near 100% write bandwidth has little room for bursts, full-page images, index builds or recovery-related work.
Capacity planning should reserve headroom for the worst representative checkpoint cycle, not only the average cycle. Measure peak data-page write rate, WAL rate and device queue depth together. If checkpoint completion repeatedly approaches the next trigger, the system is losing scheduling flexibility and can become sensitive to small workload spikes.
Checkpoint Review: Distinguish Cause From Consequence
Frequent requested checkpoints can be a consequence of high WAL generation. High WAL generation can itself be increased by frequent checkpoints through full-page images. This feedback loop means the first visible metric is not always the root cause.
Investigate from workload to WAL generation to checkpoint trigger to page writeback. Then verify whether the change reduces the original trigger rather than only suppressing the warning. Raising max_wal_size can provide breathing room, but it also increases possible recovery distance and disk requirements. Reducing application write amplification can attack the cause more directly.
Checkpoint Postconditions
When a checkpoint is declared complete, the engine’s durable data baseline and control metadata must agree. Crash recovery must be able to start from the advertised redo position and reproduce every later durable change. WAL that local recovery no longer needs must still be retained if archives, replicas or backups require it.
Those postconditions are stronger than “dirty pages were written.” They make the checkpoint a verified recovery boundary. The durability of the metadata describing that boundary is part of the checkpoint itself.
Continue: How Group Commit Works · How Database Crash Recovery Works.
Checkpoint Failure Modes Worth Rehearsing
Test a checkpoint when the storage device is slow, when WAL generation surges, when archiving is delayed and when a standby pins older WAL. These scenarios reveal whether the system preserves headroom and continues to make progress without treating every pressure source as the same problem.
Also test an abrupt crash while checkpoint writes are active. Recovery should use the last trustworthy checkpoint metadata and redo the required later work. A partially completed checkpoint must not become a false recovery boundary.
Checkpoint Operations Checklist
Monitor timed versus requested checkpoints, buffers written, checkpoint write and sync time, WAL bytes, full-page-image rate, pg_wal free space, archive lag and replication retention. After any tuning change, verify that both normal latency and measured restart time remain inside the intended service objectives.
A final checkpoint principle is to preserve slack. The database needs enough storage bandwidth and WAL headroom to finish one checkpoint before workload growth, archive lag or replication retention turns the next cycle into an emergency. Healthy checkpointing is visible as steady progress rather than repeated forced intervention. When the system approaches its limits, diagnose whether the pressure comes from dirty-page writeback, WAL generation or a consumer that prevents recycling before changing the checkpoint schedule.
One last checkpoint test is to compare the redo start position recorded after a completed checkpoint with the WAL retained on disk and the pages written during that cycle. The three should tell one coherent story: recovery has a valid starting point, required WAL remains available, and data pages older than that boundary have satisfied the checkpoint protocol.
Continue the WAL Series
How Write-Ahead Logging Works · PostgreSQL WAL Configuration · How X Works Hub