PostgreSQL WAL growth troubleshooting should begin with replication slots and the archive pipeline, not emergency disk expansion. A volume fills because WAL remains required or archiving fails, so the team must identify the consumer and prove the recovery path before deleting anything.
The source case came from a payments stack running PostgreSQL 12. WAL files stopped recycling, the backup volume grew, and Barman rejected an unsupported daemon argument. Replication appeared healthy. It was not. The team found an orphaned physical slot, corrected WAL receiving, validated the archive path, and stabilized growth with zero downtime.
The official PostgreSQL 12 replication-slot reference explains why restart_lsn matters: it marks the oldest WAL a consumer may still require. The Barman manual documents receive-wal as a foreground process and explains how streaming WAL depends on the selected slot and retention settings. Those are the two surfaces to inspect together.
Disk growth is the symptom
Adding capacity can create time, but it does not remove the retention cause. An inactive slot can keep old segments because PostgreSQL assumes the consumer may return. A broken archive command can create a different backlog. A receiver can also look configured while no current WAL is reaching the backup system.
Start with evidence from pg_replication_slots and pg_stat_replication. Identify each slot, whether it is active, its restart point, and the application expected to consume it. Compare that state with the actual standby and backup topology. If nobody can name the consumer, the slot is a risk until proven otherwise.
Capture the evidence before changing configuration. A timestamped view of slot state, archive results, filesystem growth, and receiver status gives the team a reliable comparison after the repair. It also prevents a temporary improvement from being mistaken for a resolved cause.
The broader cloud versus dedicated hardware cost review applies here. Storage price is not the full decision. Retention behavior, monitoring, operator access, and recovery time determine whether the cheaper capacity is useful or merely hides an unresolved failure.
Repair the archive path before removing a slot
A replication slot is not disposable housekeeping. Dropping the wrong slot can break a standby or backup consumer. The safe sequence is to map the consumer, verify whether it is active, confirm an alternative recovery path, and only then retire or advance a slot that is genuinely orphaned.
In the source case, the Barman build did not support the daemon argument being used. The team enabled WAL receiving through the supported process and system configuration, checked archive_command behavior and exit codes, then forced a WAL switch to prove end-to-end movement. Configuration alone was not accepted as evidence.
This is the same operating lesson behind the analysis of dependency failure and business continuity. A green component view is not a recovery guarantee. The path must be tested from production write through retention, transport, archive, and restore.
Guardrails keep the fix from expiring
After pressure is removed, right-size max_wal_size, wal_keep_size, archive_timeout, and compression for the real workload and available disk. Treat each value as part of a capacity model, not a copied default. Monitor WAL volume, archive freshness, slot lag, receiver state, and remaining time before the filesystem fills.
The medical data security operations case shows why routine checks matter. Reliable systems are built from ownership, alerts, evidence, and response steps that exist before the incident. Database recovery needs the same discipline.
Keep a runbook beside the alert. It should name the queries, expected consumers, backup owner, escalation path, and preconditions for changing a slot. The decision to remove anything must remain explicit and reversible where possible.
Frequently Asked Questions
PostgreSQL keeps WAL that the slot consumer may still need. An inactive or abandoned consumer can therefore hold old segments and create disk pressure.
No. First identify the consumer, confirm that it is no longer required, verify the backup and standby topology, and document the recovery consequence.
Check the receiver and archive status, inspect command results, trigger a clean WAL switch, and verify that the new segment arrives through the complete archive path.
Extra disk creates time but does not remove the retention cause. The slot, receiver, archive command, and recovery design still need diagnosis.
If WAL growth, replication, or backup status is unclear in a production system, book a PostgreSQL reliability consultation before the remaining disk becomes the incident clock.