PostgreSQL Replication Slots: The Safety Net That Can Sink Your Disk

The Problem Slots Solve

The primary recycles old WAL segments to free disk. But if a standby is briefly offline and the WAL it still needs has already been recycled, replication breaks with the dreaded "requested WAL segment has already been removed" — and the only fix is to rebuild the standby from scratch.

A replication slot is the primary's promise: "I will not discard WAL until this specific consumer has confirmed it." It makes replication durable across standby restarts and network blips.

Two Kinds of Slot

-- Physical slot (for streaming replicas)
SELECT pg_create_physical_replication_slot('standby1');

-- Logical slot (for logical replication / CDC tools like Debezium)
SELECT pg_create_logical_replication_slot('cdc_slot', 'pgoutput');

Inspect them all in one view:

SELECT slot_name, slot_type, active,
       pg_size_pretty(
         pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)
       ) AS retained_wal
FROM pg_replication_slots;

The Dark Side: Disk-Fill Risk

The same promise that protects you becomes a weapon when a consumer disappears. If a slot goes active = false and never comes back — a decommissioned replica, a crashed CDC connector — its restart_lsn stops advancing. The primary keeps every WAL segment since then, forever. pg_wal grows until the disk is full and the primary stops accepting writes. This is one of the most common PostgreSQL outages in the wild.

The Guardrail: max_slot_wal_keep_size

Since PostgreSQL 13 you can cap how much WAL a slot may retain:

-- postgresql.conf
max_slot_wal_keep_size = 50GB

Past this limit, PostgreSQL invalidates the lagging slot instead of filling the disk. You lose that one replica (it must be rebuilt) but the primary survives — usually the right trade-off. Check for invalidated slots via the wal_status column (extended, unreserved, lost).

Drop What You Don't Use

SELECT pg_drop_replication_slot('old_standby');

Every slot you create is a standing promise. Decommissioning a replica without dropping its slot is exactly how the disk-fill incident starts.

Why You Want This Watched Automatically

An inactive slot is invisible until the disk alarm fires at 3 a.m. PG Monitoring continuously reports each slot's retained-WAL size, active status, and growth trend, and raises an alert when a slot goes inactive while still pinning WAL — turning a midnight outage into a routine ticket.