Postgres Down or Slow: Disk Filled by WAL (pg_wal) — Space Recovery Order

When pg_wal bloats to a disk-full, Postgres enters a state where nothing works normally. Free space in the right order, then fix the actual cause — usually a dead replication slot or an archive_command failure.

What you'll see

Root causes

Orphaned replication slot never releases WAL

Slots pin WAL forever. SELECT slot_name, active, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) FROM pg_replication_slots; shows the hoarder.

archive_command failing or not configured

If archiving is on but the command fails, WAL accumulates. Check SHOW archive_mode; SHOW archive_command; and pg_stat_archiver for failed_count.

wal_keep_size too large for the volume

Aggressive keep settings (or bulk write bursts like big COPYs) can legitimately generate more WAL than the disk holds between checkpoints.

Fix it

  1. Free space safely — do NOT delete pg_wal files by hand
    # safe space: drop unused indexes? no — first: identify slots/archiver, then VACUUM isn't it either: move/drop other files or grow the volume; pg_wal files are needed for crash recovery
  2. Drop the stale replication slot (the usual WAL hog)
    SELECT * FROM pg_drop_replication_slot('<slot>');   # only if the consumer is truly gone
  3. Fix or disable the failing archive_command
    ALTER SYSTEM SET archive_command = '/bin/true';  -- temporary unblock; SELECT pg_reload_conf();
  4. Force a checkpoint to recycle completed WAL segments
    CHECKPOINT;   # then watch: SELECT pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), '0/0')) AS lsn_age; df -h
  5. Prevent recurrence: alerting + slot guards
    # monitor pg_replication_slots lag and disk at 80%; wal_keep_size sized to real retention needs

Field note

Never rm files inside pg_wal — that corrupts crash recovery. Fix the retention cause; space follows. max_wal_size misconfiguration often masquerades as 'disk full' when the real issue is a silent archiver failure.

Common questions

Can I just delete old files in pg_wal to free space?

No — WAL files aren't disposable logs; they're required for consistency and replication. Free space by fixing retention (drop dead slots, repair archive_command, CHECKPOINT) or the volume stays fragile.

Why does pg_wal grow if I have no replicas?

Check for forgotten slots (from old logical decoding experiments), archive_mode with a broken archive_command, or bulk write bursts. SELECT * FROM pg_stat_archiver and pg_replication_slots identify all three.

Ship it right the first time

Our most-documented failures, packaged as ready-to-ship starter kits: Docker, Kubernetes, and Terraform.

Browse the template store →

One-time. Yours to modify. Instant download from the NinjaOps template store.

Get new fixes by email

One short email when new fixes and production templates drop. No spam, unsubscribe anytime.

Partner pick — sponsored

Vultr — our lab-environment pick for this stack

Spin up a cloud server in 60 seconds and reproduce this fix yourself — pay by the hour.

Get Vultr →
Also vetted

Sentry — Free tier: see the exact line of code that broke, before users report it.

Get Sentry →

We earn a commission if you buy through our links — it never costs you extra. More vetted tools on our picks hub · comparing clouds? DigitalOcean vs Vultr and vs AWS · full deals: DigitalOcean · Vultr · NordLayer · Semrush