How Do You Drop a Replication Slot in PostgreSQL?

Replication slots keep PostgreSQL replicas in sync by holding on to the write ahead log (WAL) they still need. That safety net turns into a problem when a slot is left behind: it keeps WAL forever, quietly filling your disk and dragging down performance.

This guide gives you the exact command to drop a slot, shows how to find and stop a slot that is still active, explains how to stop slots from filling your disk on Postgres 13 and later, and walks through the errors people most often hit.

What Are Replication Slots in PostgreSQL?

Replication slots arrived in PostgreSQL 9.4 alongside logical decoding. A slot tracks how far a downstream consumer, such as a standby server or a logical subscriber, has read. Because the slot records that position, PostgreSQL knows which WAL it can safely recycle and which it must keep, so no changes are lost even when a consumer falls behind.

How Replication Slots Use the WAL

PostgreSQL records every change in the write ahead log. Changes first land in the WAL buffer, and once the buffer fills, they are flushed to disk as WAL segments in the pg_wal directory, each 16 MB by default. Every record carries a Log Sequence Number (LSN), a byte offset that always moves forward.

For logical replication, PostgreSQL decodes those raw WAL records into row level changes such as INSERT, UPDATE, and DELETE, and a WAL sender process streams them to each subscriber. Normally settings like wal_keep_size and checkpoints let old WAL be removed. A replication slot overrides that: it pins the WAL a consumer still needs until the consumer confirms it has caught up. That is exactly why a forgotten slot never releases its WAL.

Physical vs Logical Replication Slots

There are two kinds of slot, and both are removed with the same function.

Why Drop a Replication Slot?

Disk Space Consumption

If a replica shuts down or fails and its slot is not removed, the slot becomes an orphan. PostgreSQL keeps every WAL segment the slot claims to need, so disk usage on the primary can grow without bound until the slot is dropped. Removing slots for replicas that are offline for a long time, or gone for good, releases that space.

Performance Implications

Orphaned slots also make the server work harder. Retaining unnecessary WAL raises disk I/O and memory pressure, and over time this resource contention slows the whole instance. Dropping unused slots frees those resources for the replication that is actually running.

How to Drop a Replication Slot: Step by Step

Slots are created and removed by hand, so the safe path is to confirm a slot is idle before you remove it. Follow these five steps in order.

Step 1: List the slots and find the target

Start with a single query that shows each slot, whether it is active, which backend holds it, its WAL status, and how much WAL it is retaining:

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

The retained_wal column is the one to watch: it tells you how much disk each slot is costing you right now. The active_pid column gives you the backend process you will need if the slot turns out to be active.

Step 2: Confirm the slot is inactive

Look at the active column for your slot. A value of f (false) means no consumer is connected and the slot is safe to remove. A value of t (true) means it is still in use, so skip ahead to the section on dropping an active slot.

Step 3: Check dependents and permissions

Make sure no standby, subscription, or replication tool still relies on the slot, because removing one that is in use disrupts replication and can cause inconsistency. Also confirm you have the rights to drop it: you need to be a superuser, the owner of the slot, or a role with the REPLICATION attribute.

Step 4: Drop the slot

Remove the slot with a plain function call, using straight quotes around the slot name:

SELECT pg_drop_replication_slot('slot_name');

Step 5: Verify it is gone

Confirm the slot no longer exists. This query should return no rows:

SELECT slot_name
FROM pg_replication_slots
WHERE slot_name = 'slot_name';

How to Drop a Slot That Is Still Active

PostgreSQL will not let you drop a slot while a consumer holds it. First take the active_pid value from the query in Step 1 and terminate that backend:

SELECT pg_terminate_backend(active_pid);

Replace active_pid with the number you saw for the slot. Once the backend is gone, drop the slot before anything reconnects:

SELECT pg_drop_replication_slot('slot_name');

Watch out: If a live subscriber or standby is still configured, it can reconnect and recreate the slot moments later. Disable the consumer first, then drop the slot. See the errors section below.

Stop Slots From Filling Your Disk (Postgres 13 and Later)

The cleanest long term fix is to cap how much WAL any single slot may pin. From Postgres 13 you can set max_slot_wal_keep_size. Once a slot exceeds that limit, Postgres invalidates the slot rather than letting it fill the disk:

ALTER SYSTEM SET max_slot_wal_keep_size = '10GB';
SELECT pg_reload_conf();

After this, the wal_status column tells you where each slot stands: reserved means it is within limits, extended means it is holding extra WAL, unreserved means it is close to the cap, and lost means Postgres has invalidated it because required WAL was removed.

Version note: max_slot_wal_keep_size and the wal_status column are available from Postgres 13. On older versions you cannot cap a slot, so monitor retained_wal and drop orphaned slots promptly instead.

Common Errors and Fixes

Most problems when dropping a slot come down to one of four causes.

Does Dropping a Slot Cause Data Loss?

Dropping a slot does not delete any table data. It only stops PostgreSQL from retaining WAL on behalf of that consumer. The risk is indirect: if a consumer that genuinely still needed the slot later reconnects, the WAL it missed may already be gone, and it will need a fresh copy of the data to resync. That is why you only drop slots you have confirmed are unused.

What About Publications and Subscriptions?

A common misconception is that dropping a publication removes the slot. It does not. Publications and replication slots are separate objects. On the subscriber side, dropping a subscription removes the slot that subscription created. On the publisher side, the slot stays until you remove it yourself with pg_drop_replication_slot. If you dropped a publication and the slot is still there, drop the slot manually.

How Airbyte Manages Replication Slots in Postgres CDC

Logical replication between two PostgreSQL servers is efficient, but it only moves data from Postgres to Postgres. When you need to send Postgres data to a warehouse, a lake, or another database, a data movement platform like Airbyte handles it. Airbyte offers over 600 connectors, including PostgreSQL, so you can extract from many sources and load into the destination you choose.

Airbyte captures changes incrementally using logical replication of the Postgres WAL through a replication plugin. A typical setup looks like this:

• Configure PostgreSQL as a source in Airbyte and grant the required permissions.
• Enable logical replication on the Postgres database.
• Create a replication slot using the pgoutput plugin.
• Create a publication and set replica identities for each table.
• Enable CDC in the Airbyte UI.

Tip: If you drop a slot that Airbyte is using, disable the connection first. Otherwise Airbyte reconnects on the next sync and recreates the slot.

Conclusion

Dropping a replication slot is a one line command, but the care is in what surrounds it. Find the slot and see what it is costing, confirm it is inactive, check who depends on it, then drop it and verify. Cap WAL retention with max_slot_wal_keep_size where you can, and disable any consumer before you remove its slot. Follow that order and you can reclaim disk and performance without disturbing healthy replication.

Frequently Asked Questions

What command drops a replication slot in PostgreSQL?

Use SELECT pg_drop_replication_slot('slot_name'); with straight quotes around the slot name. The slot must be inactive, and you need superuser, owner, or REPLICATION rights.

How do I list all replication slots?

Run SELECT * FROM pg_replication_slots; for a quick view, or the fuller query in Step 1 to also see how much WAL each slot is retaining and which backend holds it.

Can I drop a replication slot that is active?

Not directly. Stop the consumer that holds it, or terminate its backend with pg_terminate_backend(active_pid), then drop the slot before anything reconnects.

Does dropping a replication slot cause data loss?

No. It stops WAL retention for that consumer but leaves your data intact. Only a consumer that still needed the slot is affected, and it would simply need to resync.

Why does my slot keep coming back after I drop it?

An active subscription, standby, or replication tool reconnects and recreates it. Disable that consumer first, then drop the slot.

Does dropping a subscription or publication drop the slot?

Dropping a subscription removes the slot it created. Dropping a publication does not. Publisher side slots must be removed manually with pg_drop_replication_slot.

How do I stop a replication slot from filling my disk?

On Postgres 13 and later, set max_slot_wal_keep_size so a slot is invalidated once it exceeds the limit rather than growing without bound. On older versions, monitor retained WAL and drop orphaned slots promptly.