This error occurs when PostgreSQL replication or logical decoding tries to use a replication slot that doesn't exist on the server. It commonly happens when slot names are misspelled, slots are dropped without updating configuration, or when connecting to the wrong database instance during replication setup.
Replication slots are PostgreSQL mechanisms that track the position of WAL (Write-Ahead Log) consumption for streaming replication and logical decoding. When you configure replication or logical decoding to use a specific slot, PostgreSQL must find that slot in its system catalog (pg_replication_slots). If the slot name doesn't match an existing slot, or if the slot was dropped, PostgreSQL cannot proceed and returns this error. Slots are instance-specific and do not replicate between servers.
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.
Slot Names Are Case-Sensitive: PostgreSQL treats slot names as case-sensitive identifiers. 'MySlot' and 'myslot' are different slots. Always double-check capitalization.
Slot Limitations: Physical replication slots cannot be created on standby servers—only on the primary. Logical replication slots can be created on the primary or subscriber, depending on the subscription setup. You cannot replicate slots between servers; each replication target needs its own slot.
WAL Retention and Disk Space: Replication slots prevent WAL files from being deleted, protecting standby servers from connection loss. However, if a standby disconnects for an extended period, the primary can fill its disk with retained WAL files. PostgreSQL 13+ introduced max_slot_wal_keep_size to limit WAL retention per slot and prevent disk exhaustion.
Replication User Permissions: The replication user account must have the REPLICATION privilege to use replication slots. Create the user with: CREATE ROLE replication_user WITH LOGIN REPLICATION PASSWORD 'password';
Slot Persistence: Replication slots persist on disk and survive server restarts. However, slots in crashed or uncleanly shut down instances may be marked as inactive. If you see inactive slots after a crash, check if the standby/consumer is truly disconnected before dropping the slot.
insufficient columns in unique constraint for partition key
How to fix "insufficient columns in unique constraint for partition key" in PostgreSQL
ERROR 42501: must be owner of table
How to fix "must be owner of table" in PostgreSQL
trigger cannot change partition destination
How to fix "Trigger cannot change partition destination" in PostgreSQL
SSL error: certificate does not match host name
SSL error: certificate does not match host name in PostgreSQL
No SSL connection
No SSL connection to PostgreSQL