log_recovery_conflict_waits
Read PG 18 manual ↗Controls whether a log message is produced when the startup process waits longer than deadlock_timeout for recovery conflicts.
- Type
- bool
- Context
- sighup
- Measured default
- off
- Unit
- —
- Metadata snapshot
- 18
Definition PG 18 manual
Controls whether a log message is produced when the startup process waits longer than deadlock_timeout for recovery conflicts. This is useful in determining if recovery conflicts prevent the recovery from applying WAL.
The default is off. This parameter can only be set in the postgresql.conf file or on the server command line.
Measured default history
| Version interval | Default |
|---|---|
| 14 – 19 | off |
Authored guidance from the GUC source snapshot; the version-specific manual above is the definition reference. View source ↗
How it works
log_recovery_conflict_waits logs standby recovery conflict waits. On a standby, recovery conflict waits are reported after deadlock_timeout, exposing replay delays before cancellation is necessarily required.
log_recovery_conflict_waits is a SIGHUP-context setting: a configuration reload activates the new server value without a restart; subsequent operations that consult it use the refreshed value.
It changes emitted diagnostic data rather than query semantics, but volume, sensitive content, log_line_prefix, destinations, collector throughput, and retention determine operational cost and usefulness.
Operational considerations
Editing log_recovery_conflict_waits without reloading configuration and verifying the effective value and subsequent behavior.
Enabling richer logging without budgeting collector throughput, storage, retention, and downstream query cost.
Writing SQL text, bind values, identities, or host data without a redaction and access-control policy.
Changing log_recovery_conflict_waits globally without a rollback plan and a client or operational compatibility test.
Workload guidance
OLAP: Analytical jobs can justify richer log_recovery_conflict_waits telemetry, but account for long statements, large bind values, and bursty completion patterns in the log pipeline.
OLTP: Tune log_recovery_conflict_waits against an explicit observability question and a measured log-volume budget. Prefer selective thresholds, sampling, or role-level overrides over indiscriminate capture.
SMALL: Keep log_recovery_conflict_waits useful but bounded: verify disk, collector, retention, and redaction capacity before increasing detail or frequency.
Version history 1
- PG 13 → 14added
Related entries
Further reading
Definition snapshot: english-manuals:17b8d714f2610ced6b891b56cff… · English manual source