Parameter · Reporting and Logging / What to Log
log_recovery_conflict_waits
Logs standby recovery conflict waits.
- Default:
off - Type: bool
- Applies: Reload
In plain words
On a hot standby, replaying changes from the primary sometimes has to wait because a read-only query still needs old data. With this on, the standby logs when such a wait passes deadlock_timeout, and again when it ends, so you can see what delays replication.
For DBAs and operators
PostgreSQL 14+. Captured on an 18.6 standby (deadlock_timeout = 500ms, max_standby_streaming_delay = 3s):
Conflict kinds: snapshot (vacuum removed rows a query may need), lock (e.g. replayed ACCESS EXCLUSIVE), buffer pin, tablespace, database, and replication slot. Each wait means the standby's replay, and thus its lag, stalls. The final cancel is governed by max_standby_streaming_delay / max_standby_archive_delay.
Use the logs together with pg_stat_database_conflicts to decide between hot_standby_feedback = on (no snapshot conflicts, but bloat on the primary), larger delays (more lag), or moving long reports elsewhere.
How to change it
Change in postgresql.conf or ALTER SYSTEM, then run SELECT pg_reload_conf().
See it in context
Hot standby and recovery conflicts Startup process Streaming replication
Related parameters
max_standby_streaming_delay max_standby_archive_delay hot_standby_feedback deadlock_timeout log_lock_waits