Generated Oct 14, 2026, 9:39:02 AM
Do not rm or permanently delete WAL files that are still referenced by replication slots. If you must free space, move (mv) WAL files to a separate disk or compress them to a temporary location, but preserve them for potential replay.
On the subscriber host, check postgresql logs and system logs around the disconnect time for WAL receiver crashes, OOM, or I/O stalls; restart the subscriber Postgres cleanly and confirm it can connect and resume replication.
Run SELECT slot_name, plugin, active, restart_lsn, confirmed_flush_lsn FROM pg_replication_slots; on primary and compare confirmed_flush_lsn to current WAL LSN to estimate backlog. On subscriber, check pg_stat_wal_receiver and pg_last_wal_receive_lsn() to confirm progress.
If subscriber is permanently lost and you have a recent base backup, consider creating a new slot and/or reinitialising the subscriber via pg_basebackup; when reinitialising, drop the old slot only after ensuring subscriber re-creation or that no other consumers need it.
Implement slot monitoring and alerting (e.g., warn if WAL retention > X GB or confirmed_flush_lsn behind > Y MB). Consider setting max_slot_wal_keep_size (Postgres 13+) to limit WAL retention impact, or schedule base backups more frequently during heavy loads to allow safe WAL removal through archiving policies (test first). Read-only delay: throttle bulk loads or run them on replicas to avoid overwhelming replication consumers during peak times where possible (reconfigure COPY batching). Escalate to DBA or vendor support if logical decoding/pglogical shows internal errors or if WAL records required by slot were accidentally removed.