trace_recovery_messages

trace_recovery_messages — Enables logging of recovery-related debugging information. Observed in PG9.0–16; its last measured boot default is log in PG16, with sighup context. It was removed in PG17.

Note

Fact — official short description: “Enables logging of recovery-related debugging information.”

Identity

Type , Valueenum: Upstream pg_settings type
Context , Valuesighup: Takes effect after configuration reload
Unit , Value—: Raw unit
Range , Value—: Raw limits in the last observed version
Enum values , Valuedebug5, debug4, debug3, debug2, debug1, log, notice, warning, error: — for non-enum types
Category , ValueDeveloper Options: Upstream classification
Latest boot value , Valuelog: log

Lifecycle

Fact	Value
First observed	PG9.0 (research boundary)
Present in	PG9.0–16
Removed in	PG17
Introduction commit	Not asserted: predates the PG9.0 research boundary
Commit date	—
Discussion	—

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG9.0–16	`log`	—	log

How it works

Through PG16, trace_recovery_messages remapped recovery DEBUG messages at or above a chosen severity to LOG, making normally hidden recovery internals visible during testing.

It changed message visibility, not recovery decisions, WAL replay order, or durability. Verbose recovery logging could be extremely large and timing-sensitive.

PostgreSQL 17 removed the parameter. Upgrade configurations must delete it; current recovery diagnosis should use supported logging, progress, and WAL inspection facilities. Its SIGHUP context allows configuration reload without a server restart.

Tuning advice

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload	Guidance
OLTP	Do not configure trace_recovery_messages on current PostgreSQL. Remove it during upgrades; use any named successor only for the same controlled developer test, not as a production default.
OLAP	Analytical workload does not justify retaining the removed trace_recovery_messages. Diagnose current versions with supported EXPLAIN, logs, or the documented replacement.
Small nodes	Delete trace_recovery_messages from modern configurations. Unknown-parameter startup failure and diagnostic overhead outweigh any historical use.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG16; this does not assert current Pigsty support for that historical or beta release.

Template	Effective value	Versus upstream boot	Source expression
OLTP	Unmodified	—	—
OLAP	Unmodified	—	—
CRIT	Unmodified	—	—
TINY	Unmodified	—	—

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG9.0–16 unmodified; OLAP: PG9.0–16 unmodified; CRIT: PG9.0–16 unmodified; TINY: PG9.0–16 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

Leaving trace_recovery_messages enabled after the bounded diagnostic or recovery task.
Running the experiment on the only copy of production data.
Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
Treating a server that merely starts or completes a query as proof that data and behavior are correct.

log_min_messages · restore_command · recovery_min_apply_delay · wal_consistency_checking