PGthesev1database
ErrorsTriageCookbook
ArchitectureLessonsInterview
Pricing
Runbooks/WAL & replication

Runbook category

WAL & replication

WAL is the cost centre nobody measures until pg_wal fills the disk. These runbooks measure it instead of guessing: bytes generated per workload, what an abandoned replication slot pins, what wal_compression actually saves (less than the blog posts claim), and how checkpoint pacing turns a flat totals graph into periodic latency spikes.

  • Reclaim WAL held by an inactive replication slot

    pg_wal keeps growing and the replica the slot was created for is long gone.

    Pro
  • Measure your WAL generation rate

    Archiving and disk sizing need a WAL bytes-per-hour number nobody has measured.

    Pro
  • Flatten checkpoint I/O spikes by tuning checkpoints

    Latency spikes on a regular cadence while the totals graph stays perfectly flat.

    Pro
  • Size WAL with max_wal_size and checkpoint_timeout

    max_wal_size copied from a blog post, never checked against your own WAL rate.

    Pro
  • Reduce WAL volume with wal_compression

    Full-page images dominate the WAL stream on an update-heavy workload.

    Pro
  • Right-size synchronous_commit for latency

    Tiny transactions spend most of their life waiting for WAL to reach durable storage.

    Pro
  • Find unlogged tables before a crash empties them

    A table came back empty after an unclean restart, and no backup or replica has the rows.

    Pro

Other categories

Query performance16Indexing9Vacuum & bloat8Locking & concurrency7Observability16Schema migrations6

Browse all runbooks →

thesev1database

Evidence-first PostgreSQL reference. Every claim is reproduced in a Docker lab and cited back to the official manual — no hand-waving.

Firefight

ErrorsTriageCookbook

Learn

ArchitectureLessonsPathwaysLibrary mapGlossaryGUCsInterview prep

More

PricingSign in

Company

ContactTermsPrivacyRefunds