How to fix Replication slot does not exist in PostgreSQL

Connect to the primary PostgreSQL server and check what slots currently exist:

SELECT slot_name, slot_type, active FROM pg_replication_slots;

This query shows:
- slot_name: The exact name of each slot
- slot_type: Either 'physical' (for streaming replication) or 'logical' (for logical decoding)
- active: Whether the slot is currently in use (true/false)

Verify that the slot you're trying to use is listed here with the exact spelling. Note: This query must be run on the primary server, not a standby.

Replication slots are instance-specific. Confirm your connection details match the primary server:

# Check current connection details
psql -h <host> -p <port> -U <user> -d postgres -c "SELECT version();"

Also verify the connection string in your replication or logical decoding configuration. Common mistakes:
- Connecting to a standby server (slots only exist on primary)
- Connecting to the wrong host due to DNS issues
- Connecting to localhost when you meant a remote server
- Using an environment variable that points to a different instance

If the slot doesn't exist, create it on the primary server.

For physical replication (streaming replication):

SELECT pg_create_physical_replication_slot('slot_name');

For logical replication/decoding:

SELECT pg_create_logical_replication_slot('slot_name', 'pgoutput');

Replace 'slot_name' with your desired slot name. The slot_name must match exactly what your standby or consumer is configured to use. PostgreSQL slot names are case-sensitive.

If the slot exists but your configuration is referencing the wrong name, update it.

For streaming replication, in recovery.conf (PostgreSQL 11 and earlier) or postgresql.conf:

# In recovery.conf or as ALTER SYSTEM command
primary_slot_name = 'your_slot_name'

Using ALTER SYSTEM (PostgreSQL 12+):

ALTER SYSTEM SET primary_slot_name = 'your_slot_name';
-- Then reload configuration
SELECT pg_reload_conf();

For logical decoding (in your application config):

Update the slot name to match exactly. No quotes or spaces.

Slots can cause disk usage issues. Review and clean up:

-- View slot details with retention info
SELECT slot_name, slot_type, active, restart_lsn FROM pg_replication_slots;

-- Check WAL size retained by slots
SELECT slot_name, pg_wal_lsn_diff(write_lsn, restart_lsn) as wal_retained FROM pg_replication_slots;

If a slot is inactive (active = false) and no longer needed, drop it:

SELECT pg_drop_replication_slot('old_slot_name');

Never drop a slot that an active standby or consumer is using. Coordinate with your replication team first.

Once the slot is created and configuration is updated, test the connection:

For streaming replication:

# From standby server, test connection to primary with slot
psql -h <primary_host> -p <port> -U <replication_user> -d postgres -c "IDENTIFY_SYSTEM;"

For logical decoding:

# Test using test_decoding plugin (if installed)
psql -h <host> -p <port> -U <user> -d postgres -c "CREATE SUBSCRIPTION test_sub CONNECTION 'dbname=postgres host=<host>' PUBLICATION mypub WITH (slot_name='your_slot_name');"

If the connection succeeds without the 'slot does not exist' error, your replication is configured correctly.