What should we do when an inactive replication slot is filling the database disk?

If an inactive replication slot is filling disk, do not drop it reflexively. First identify the consumer, estimate how long until storage is exhausted, and decide whether that consumer can resume from the slot, must be reseeded from a fresh snapshot, or is gone and should be retired. PostgreSQL replication slots persist without an active connection and can retain WAL indefinitely, so the emergency action is to protect disk while preserving the only recovery path you may still have.

Why is an inactive slot filling disk?

A PostgreSQL replication slot survives its consumer disconnecting. The server continues retaining the WAL and other resources needed for that consumer to resume, even while the slot has no active connection (PostgreSQL logical decoding concepts). That is useful when a consumer is briefly paused. It is dangerous when the consumer is dead or badly behind.

This is why the first question is operational, not theoretical: is the downstream system merely disconnected, or has it lost the ability to continue from that point?

Should you resume, reseed, or retire?

Choose resume when the consumer still exists, can reconnect soon, and your disk runway comfortably exceeds the catch-up period. This is the least disruptive path because the slot preserves an ordered stream of changes for exactly one consumer at a time (PostgreSQL logical decoding concepts).

Choose reseed when the consumer is too far behind, its local state is corrupt, or your disk will fill before catch-up completes. In that case, create a fresh snapshot for the downstream system and restart replication from a new known-good position. This accepts reinitialization work in exchange for stopping unbounded WAL retention.

Choose retire when the consumer is gone for good. Remove the obsolete slot so it no longer holds resources for an abandoned replication path, following the PostgreSQL logical decoding guidance. Dropping an active-but-needed slot, though, can force data loss for that downstream path, so confirm ownership first.

How much disk runway do you really have?

Measure retained WAL growth against free space now. Your decision window is smaller than total free disk because checkpoints, autovacuum, and normal write traffic still need headroom. If the slot is retaining tens of gigabytes and the primary is generating WAL quickly, a “wait and see” plan is usually the wrong one.

Also set a future guardrail. PostgreSQL provides max_slot_wal_keep_size, which limits how much WAL replication slots may retain at checkpoint time (PostgreSQL replication settings). That setting does not rescue a broken consumer automatically, but it turns an unbounded disk risk into a defined recovery contract: beyond this limit, the consumer may need reseeding instead of catch-up.

What does a good decision checklist look like?

Worked example:

A CDC consumer has been offline for 9 hours. The slot has retained 120 GB of WAL. The database has 180 GB free, and normal workload consumes another 20 GB during peak periods.

1. Confirm the owner of the slot and whether the consumer can still read from its last durable position.
2. Estimate catch-up time versus remaining safe disk headroom.
3. If reconnect and catch-up fit safely, resume the consumer immediately.
4. If not, stop treating the slot as the recovery plan. Reseed the consumer from a fresh snapshot, then drop or replace the old slot.
5. After recovery, set max_slot_wal_keep_size to a value aligned with the longest acceptable outage.

In this example, I would reseed unless the consumer can reconnect immediately and catch up well before free space becomes critical.

Follow-up Q&A

Can I just increase disk and deal with it later?
You can, but that only buys time. If the consumer cannot recover from the retained position, more disk delays the same decision.

Will dropping the slot free space safely?
It frees PostgreSQL to remove no-longer-needed WAL, but only do it after deciding that the downstream can be retired or rebuilt from a fresh snapshot.

Your next step: inventory every replication slot, assign an owner and recovery method, and set a retained-WAL limit before the next inactive consumer turns into a storage incident.

Reviewed: 2026-09-05