select open change scope Open full search

PG.CENTER connects PostgreSQL documentation, reference, and ecosystem knowledge. Maintained by Pigsty.

CONFIGURATION / REPORTING AND LOGGING

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 intervalDefault
14 – 19off
Analysis & operational context

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
  1. PG 13 → 14added

Related entries

Further reading

Definition snapshot: english-manuals:17b8d714f2610ced6b891b56cff… · English manual source