The essentials

Quick reference

One focused task per row. Jump to the related section for complete, working examples.

UseSyntaxExamples
Check fsyncSHOW fsync;View examples
Check full-page writesSHOW full_page_writes;View examples
Inspect the sync methodSHOW wal_sync_method;View examples
Use durable local commitSET LOCAL synchronous_commit = on;View examples
Allow asynchronous commitSET LOCAL synchronous_commit = off;View examples
Wait for replaySET LOCAL synchronous_commit = remote_apply;View examples
Show checkpoint intervalSHOW checkpoint_timeout;View examples
Show WAL soft limitSHOW max_wal_size;View examples
Spread checkpoint writesALTER SYSTEM SET checkpoint_completion_target = 0.9;View examples
Inspect checkpoint countersSELECT * FROM pg_stat_checkpointer;View examples
Inspect WAL generationSELECT wal_records, wal_fpi, wal_bytes, wal_buffers_full FROM pg_stat_wal;View examples
Check archive statusSELECT archived_count, failed_count, last_failed_wal, stats_reset FROM pg_stat_archiver;View examples
Check replication slotsSELECT slot_name, active, restart_lsn, wal_status FROM pg_replication_slots;View examples
Request a WAL switchSELECT pg_switch_wal();View examples
Force a checkpointCHECKPOINT;View examples
Check checkpoint role membershipSELECT pg_has_role(current_user, 'pg_checkpoint', 'MEMBER');View examples
Read the current WAL LSNSELECT pg_current_wal_lsn();View examples
Inspect checksum stateSHOW data_checksums;View examples

Write-ahead logging protects committed changes by flushing WAL before affected data pages. Checkpoints bound recovery work but create write pressure and full-page-image churn; durability depends on honest storage, correct fsync behavior, adequate WAL capacity, and tested backups—not one isolated setting.

Step by step

Detailed examples

01

Preserve the WAL-before-data durability contract

fsync and full_page_writes protect against operating-system or torn-page failures, while wal_sync_method selects the flushing primitive. Turning fsync off can cause unrecoverable corruption after a crash, and changing full_page_writes is not a substitute. Storage must truthfully honor flush requests; benchmark with production-equivalent hardware.

Audit core durability settings
SELECT name, setting, source
FROM pg_settings
WHERE name IN ('fsync', 'full_page_writes', 'wal_sync_method', 'synchronous_commit')
ORDER BY name;
Back to quick reference ↑
02

Separate local commit durability from standby acknowledgement

synchronous_commit can be changed per transaction. off may acknowledge before local WAL flush, risking recent transactions after an OS or power failure but not database inconsistency; remote_write, on, remote_apply, and local have different standby semantics when synchronous replication is configured. It does not make a standby synchronous by itself.

Relax durability for rebuildable telemetry only
BEGIN;
SET LOCAL synchronous_commit = off;
INSERT INTO app.telemetry(event_at, payload) VALUES (clock_timestamp(), '{"source":"edge"}');
COMMIT;

Note: Use only where bounded loss is acceptable; replicas and crash recovery can temporarily lag acknowledged commits.

Back to quick reference ↑
03

Balance checkpoint frequency, recovery time, and write amplification

Automatic checkpoints start at checkpoint_timeout or when max_wal_size is about to be exceeded. max_wal_size is a soft limit and can be exceeded by archiving failures, slots, retention, or load. Too-frequent checkpoints increase page flushing and full-page images; checkpoint_completion_target spreads most work across the interval.

Inspect checkpoint configuration together
SELECT name, setting, unit, source
FROM pg_settings
WHERE name IN ('checkpoint_timeout', 'checkpoint_completion_target', 'max_wal_size', 'min_wal_size')
ORDER BY name;
Back to quick reference ↑
04

Use cumulative statistics instead of intuition

PostgreSQL 18 exposes checkpoint and restartpoint counters in pg_stat_checkpointer and WAL activity in pg_stat_wal. Snapshot values over time because counters are cumulative and can reset. In PostgreSQL 18, num_timed and num_requested include skipped checkpoints, while num_done counts completed checkpoints; high request rates, long write or sync time, and rising full-page images guide different remedies.

Read checkpoint pressure
SELECT num_timed, num_requested, num_done, write_time, sync_time, buffers_written, stats_reset
FROM pg_stat_checkpointer;
Back to quick reference ↑
05

Capacity WAL for replication, archiving, and slots

Old segments remain when archiving fails, replication slots retain WAL, wal_keep_size applies, or summarization is incomplete. max_wal_size does not cap these cases. Monitor pg_wal capacity, slot restart_lsn, archive failures, and standby lag together; abandoned slots can fill the volume and stop the primary.

Estimate retained WAL per physical slot
SELECT slot_name, active, restart_lsn,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained
FROM pg_replication_slots
WHERE slot_type = 'physical';

Note: Access may require pg_monitor or elevated privileges; NULL restart_lsn needs separate interpretation.

Back to quick reference ↑
06

Force checkpoints only for a specific operational reason

CHECKPOINT flushes dirty buffers and can create an I/O spike; it is not normal maintenance. Only superusers or members of pg_checkpoint can run it, and during recovery it requests a restartpoint. Never schedule frequent manual checkpoints as a substitute for correct configuration.

Confirm privilege before an exceptional checkpoint
SELECT pg_has_role(current_user, 'pg_checkpoint', 'MEMBER') AS may_checkpoint;
-- Run CHECKPOINT separately only when an approved runbook requires it.
Back to quick reference ↑
07

Treat WAL as one part of tested recovery

Crash recovery uses WAL from the latest checkpoint, while PITR requires a compatible base backup plus every required archived segment. Replication is not a backup and WAL files must never be manually deleted. Data checksums detect many storage corruptions but do not replace backups or full-page writes.

Record the current WAL position for an operational timeline
SELECT pg_current_wal_lsn() AS primary_lsn, pg_current_wal_insert_lsn() AS insert_lsn;

Note: These functions are meaningful on a primary and may require monitoring privileges depending on the deployment.

Back to quick reference ↑

Sources and further reading

References

Authoritative documentation used to verify and expand this cheat sheet.

  1. PostgreSQL Global Development GroupReliability and the Write-Ahead Logpostgresql.org
  2. PostgreSQL Global Development GroupWrite-Ahead Loggingpostgresql.org
  3. PostgreSQL Global Development GroupWAL Configurationpostgresql.org
  4. PostgreSQL Global Development GroupWrite Ahead Log Settingspostgresql.org
  5. PostgreSQL Global Development GroupReplication Settingspostgresql.org
  6. PostgreSQL Global Development GroupMonitoring Database Activitypostgresql.org
  7. PostgreSQL Global Development GroupCHECKPOINTpostgresql.org
  8. PostgreSQL Global Development GroupContinuous Archiving and PITRpostgresql.org

Help us improve

Found a typo or missing example?

Tell us what would make this cheat sheet clearer, more complete, or more useful.

Share feedback