The Problem: A Slow or Offline Replica
Imagine a Primary server generating 1 GB of WAL per minute. To save disk space, it automatically deletes old WAL segments after they've been sent to all replicas. Now a replica goes offline for two hours due to a network outage. When it comes back, it asks the Primary for WAL data from two hours ago — but the Primary already deleted it. The replica is now permanently broken and must be rebuilt from scratch by taking a full base backup of the Primary and re-streaming. On a large database, this can take hours.
The Solution: Replication Slots
A Replication Slot is a persistent bookmark the Primary maintains for each replica. The Primary makes a guarantee: "I will not delete any WAL segment that this slot still needs, regardless of how long it takes." PostgreSQL's pg_replication_slots view exposes each slot's restart_lsn, from which you can compute a lag_size (the gap between it and the current WAL position) — this is the critical metric to monitor.
The Hidden Danger: Disk Exhaustion
Replication slots solve the "broken replica" problem but introduce a new one. If a replica is offline for a long time, the Primary accumulates WAL indefinitely. A Primary with a 500 GB disk could fill it entirely with retained WAL, causing the Primary itself to crash with an "out of disk space" error — taking down your entire write path.
The operational rule: monitor lag_size for every replication slot and alert aggressively. If a slot's lag exceeds a safe threshold (e.g., 10 GB), either fix the replica immediately or drop the slot with SELECT pg_drop_replication_slot('replica_1_slot') and accept that the replica must be rebuilt. A crashed Primary is far worse than a replica that needs rebuilding.