recovery_target_lsn

recovery_target_lsn sets the LSN of the write-ahead log location 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 LSN of the write-ahead log location 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 LSN of the write-ahead log location up to which recovery will proceed. The value is fixed when the server starts, so changing it requires a restart.

Recovery replays up to a pg_lsn location, with recovery_target_inclusive selecting the side of the boundary. The LSN must lie on the chosen recovery timeline and be reachable from the base backup’s WAL chain.

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_lsn 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

Using an LSN from a different cluster or a timeline not descended from the base backup.
Setting another recovery target selector at the same time.
Choosing inclusive without identifying which WAL record must be included.
Requesting an LSN beyond the available archive/streaming WAL and getting an unreachable target.
Comparing LSNs as ordinary decimal numbers instead of pg_lsn values.

recovery_target · recovery_target_time · recovery_target_xid · recovery_target_name · recovery_target_inclusive · recovery_target_action