The essentials
Quick reference
One focused task per row. Jump to the related section for complete, working examples.
| Use | Syntax | Examples |
|---|---|---|
| Check fsync | SHOW fsync; | View examples |
| Check full-page writes | SHOW full_page_writes; | View examples |
| Inspect the sync method | SHOW wal_sync_method; | View examples |
| Use durable local commit | SET LOCAL synchronous_commit = on; | View examples |
| Allow asynchronous commit | SET LOCAL synchronous_commit = off; | View examples |
| Wait for replay | SET LOCAL synchronous_commit = remote_apply; | View examples |
| Show checkpoint interval | SHOW checkpoint_timeout; | View examples |
| Show WAL soft limit | SHOW max_wal_size; | View examples |
| Spread checkpoint writes | ALTER SYSTEM SET checkpoint_completion_target = 0.9; | View examples |
| Inspect checkpoint counters | SELECT * FROM pg_stat_checkpointer; | View examples |
| Inspect WAL generation | SELECT wal_records, wal_fpi, wal_bytes, wal_buffers_full
FROM pg_stat_wal; | View examples |
| Check archive status | SELECT archived_count,
failed_count,
last_failed_wal,
stats_reset
FROM pg_stat_archiver; | View examples |
| Check replication slots | SELECT slot_name, active, restart_lsn, wal_status
FROM pg_replication_slots; | View examples |
| Request a WAL switch | SELECT pg_switch_wal(); | View examples |
| Force a checkpoint | CHECKPOINT; | View examples |
| Check checkpoint role membership | SELECT pg_has_role(current_user, 'pg_checkpoint', 'MEMBER'); | View examples |
| Read the current WAL LSN | SELECT pg_current_wal_lsn(); | View examples |
| Inspect checksum state | SHOW 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
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.
SELECT name, setting, source
FROM pg_settings
WHERE name IN ('fsync', 'full_page_writes', 'wal_sync_method', 'synchronous_commit')
ORDER BY name; 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.
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.
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.
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; 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.
SELECT num_timed, num_requested, num_done, write_time, sync_time, buffers_written, stats_reset
FROM pg_stat_checkpointer; 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.
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.
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.
SELECT pg_has_role(current_user, 'pg_checkpoint', 'MEMBER') AS may_checkpoint;
-- Run CHECKPOINT separately only when an approved runbook requires it. 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.
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.
Sources and further reading
References
Authoritative documentation used to verify and expand this cheat sheet.
- PostgreSQL Global Development GroupReliability and the Write-Ahead Logpostgresql.org
- PostgreSQL Global Development GroupWrite-Ahead Loggingpostgresql.org
- PostgreSQL Global Development GroupWAL Configurationpostgresql.org
- PostgreSQL Global Development GroupWrite Ahead Log Settingspostgresql.org
- PostgreSQL Global Development GroupReplication Settingspostgresql.org
- PostgreSQL Global Development GroupMonitoring Database Activitypostgresql.org
- PostgreSQL Global Development GroupCHECKPOINTpostgresql.org
- 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.



