WAL streaming failures in PostgreSQL replication occur when standby servers cannot connect to replication slots or when slots are missing. Common causes include deleted replication slots, case sensitivity issues, or reaching the maximum number of replication slots.
The "Could not start WAL streaming" error occurs in PostgreSQL streaming replication when a standby server attempts to initiate WAL (Write-Ahead Log) streaming from a primary server but encounters a failure. This typically means the standby cannot begin receiving transaction logs needed to stay synchronized with the primary. The error most commonly appears as "FATAL: could not start WAL streaming: ERROR: replication slot does not exist", indicating the replication infrastructure is not properly configured or has been disrupted. Streaming replication is PostgreSQL's mechanism for continuous data synchronization between primary and standby servers, and any interruption in WAL streaming means the standby cannot receive updates and will fall out of sync with the primary.
Connect to the primary PostgreSQL server and check if the replication slot exists:
SELECT * FROM pg_replication_slots;Look for your replication slot in the output. If it's missing, the slot needs to be recreated. Note the exact slot name (case-sensitive).
Verify that streaming replication is enabled on the primary:
SHOW wal_level;
SHOW max_wal_senders;
SHOW max_replication_slots;Ensure:
- wal_level is set to replica or logical (not minimal)
- max_wal_senders is greater than 0 (at least 2 for one standby plus backups)
- max_replication_slots is at least the number of standby servers you have
If changes are needed, edit postgresql.conf and restart the primary server.
If the slot does not exist from Step 1, recreate it on the primary server:
-- For physical replication (streaming replication)
SELECT pg_create_physical_replication_slot('your_slot_name');
-- For logical replication (if applicable)
SELECT pg_create_logical_replication_slot('your_slot_name', 'test_decoding');Replace your_slot_name with your actual slot name. Use the exact same name in the standby's configuration.
On the standby server, check the recovery configuration file (recovery.conf in PostgreSQL 11 and earlier, or signal files in PostgreSQL 12+).
For PostgreSQL 12+, ensure these files exist:
- standby.signal (to enable standby mode)
- postgresql.conf with primary_conninfo pointing to the primary
Example primary_conninfo:
primary_conninfo = 'host=192.168.1.100 port=5432 user=replication password=your_password'Ensure the replication slot name matches exactly (case-sensitive) with what exists on the primary.
After configuration is verified, restart the PostgreSQL standby server:
sudo systemctl restart postgresql
# or
sudo pg_ctl restart -D /path/to/data/directoryMonitor the logs for connection attempts and errors:
tail -f /var/log/postgresql/postgresql.logOnce the standby connects, verify replication is working on the primary:
SELECT usename, application_name, state, sync_state FROM pg_stat_replication;You should see your standby in the results with a state of streaming. Monitor replication lag:
SELECT slot_name, slot_type, restart_lsn FROM pg_replication_slots;For Patroni clusters, ensure all replicas are configured with identical replication slot names and that Patroni's bootstrap configuration creates slots before replicas attempt to connect. If using logical replication instead of physical, the slot must be created with pg_create_logical_replication_slot and the output plugin must exist. In high-availability setups, monitor pg_wal disk usage to prevent the primary from running out of space while waiting for slow replicas. Consider setting wal_keep_size to retain additional WAL segments as a safety buffer. If replication slots accumulate (become inactive), use pg_drop_replication_slot('slot_name') to clean them up, but only after confirming the corresponding standby no longer exists.
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