recovery_target_name

recovery_target_name sets the named restore point up to which recovery will proceed. It is a postmaster setting present in PG12–18; the latest recorded boot default is empty.

Note

Fact — official short description: “Sets the named restore point up to which recovery will proceed.”

Identity

Type , Valuestring: Upstream pg_settings type
Context , Valuepostmaster: Requires a server restart
Unit , Value—: Raw unit
Range , Value—: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueWrite-Ahead Log / Recovery Target: Upstream classification
Latest boot value , Value"": empty string

Lifecycle

Fact	Value
First observed	PG12
Present in	PG12–19 Beta 3
Removed in	No
Introduction commit	`2dedf4d9a899` — Integrate recovery.conf into postgresql.conf
Commit date	2018-11-25
Discussion	thread 1

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG12–19 Beta 3	`""`	—	empty string

How it works

Sets the named restore point up to which recovery will proceed. The value is fixed when the server starts, so changing it requires a restart.

Recovery stops at a restore point previously recorded by pg_create_restore_point(). Restore-point names are meaningful only if the corresponding WAL record is present on the selected timeline.

At most one of recovery_target, recovery_target_lsn, recovery_target_name, recovery_target_time, and recovery_target_xid may be set; timeline, inclusive, and action are modifiers. Rehearse from the same base backup through a complete WAL chain—an unreachable target makes targeted recovery fail.

Tuning advice

Tip

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

Workload	Guidance
OLTP	This is not a steady-state performance knob. Set recovery_target_name only on an isolated recovery instance after recording target evidence, base backup, timeline, and expected boundary; rehearse and require a second-person review.
OLAP	For a large restore, budget WAL replay and inspection time first. Validate the reached point read-only; do not let heavy analytical queries delay or contaminate the recovery decision.
Small nodes	Prefer a backup tool that generates a controlled recovery configuration. Never leave target settings in ordinary primary/standby templates, and clean up signal files and targets afterward.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; 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: PG12–19 Beta 3 unmodified; OLAP: PG12–19 Beta 3 unmodified; CRIT: PG12–19 Beta 3 unmodified; TINY: PG12–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

Naming a restore point whose WAL record is absent from the selected timeline.
Assuming recovery_target_inclusive changes a named restore-point boundary.
Setting another recovery target selector at the same time.
Mistyping a case-sensitive restore-point name and making the target unreachable.
Creating a business label without recording the cluster, timeline, and base-backup relationship.

recovery_target · recovery_target_time · recovery_target_xid · recovery_target_lsn · recovery_target_inclusive · recovery_target_action