select open change scope Open full search

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

CONFIGURATION / WRITE-AHEAD LOG

recovery_target_inclusive

Read PG 18 manual ↗

Specifies whether to stop just after the specified recovery target (on), or just before the recovery target (off).

Type
bool
Context
postmaster
Measured default
on
Unit
Metadata snapshot
18

Definition PG 18 manual

Specifies whether to stop just after the specified recovery target (on), or just before the recovery target (off). Applies when recovery_target_lsn, recovery_target_time, or recovery_target_xid is specified. This setting controls whether transactions having exactly the target WAL location (LSN), commit time, or transaction ID, respectively, will be included in the recovery. Default is on.

Measured default history
Version intervalDefault
12 – 19on
Analysis & operational context

Authored guidance from the GUC source snapshot; the version-specific manual above is the definition reference. View source ↗

How it works

Chooses which side of an exact recovery boundary is retained. The value is read when targeted recovery starts.

on stops just after and includes the target LSN, commit time, or XID; off stops just before and excludes it. The setting applies only to recovery_target_lsn, recovery_target_time, and recovery_target_xid.

It has no effect on immediate or named restore-point targets. Select the boundary from identified WAL/business evidence and validate recovered rows and transactions, not only the displayed timestamp or LSN.

Operational considerations

Expecting it to affect immediate or named restore-point targets.

Selecting on/off without identifying the exact boundary transaction or WAL record.

Assuming equal timestamps imply one deterministic commit boundary.

Validating only the reported replay position instead of recovered application data.

Leaving the value in a reusable recovery template without documenting the intended side of the boundary.

Workload guidance

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.

OLTP: This is not a steady-state performance knob. Set recovery_target_inclusive only on an isolated recovery instance after recording target evidence, base backup, timeline, and expected boundary; rehearse and require a second-person review.

SMALL: 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.

Version history 1
  1. PG 11 → 12added

Related entries

Further reading

Definition snapshot: english-manuals:6f1148096969af3776a5745b4db… · English manual source