recovery_target_xid
Read PG 18 manual ↗This parameter specifies the transaction ID up to which recovery will proceed.
- Type
- string
- Context
- postmaster
- Measured default
- Empty string
- Unit
- —
- Metadata snapshot
- 18
Definition PG 18 manual
This parameter specifies the transaction ID up to which recovery will proceed. Keep in mind that while transaction IDs are assigned sequentially at transaction start, transactions can complete in a different numeric order. The transactions that will be recovered are those that committed before (and optionally including) the specified one. The precise stopping point is also influenced by recovery_target_inclusive.
Measured default history
| Version interval | Default |
|---|---|
| 12 – 19 | Empty string |
Authored guidance from the GUC source snapshot; the version-specific manual above is the definition reference. View source ↗
How it works
Sets the transaction ID up to which recovery will proceed. The value is fixed when the server starts, so changing it requires a restart.
The target is a commit record for the named transaction ID, not a simple numeric ordering of all transactions: XIDs are assigned at start and can commit out of order. recovery_target_inclusive controls whether that target transaction is included.
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.
Operational considerations
Assuming numeric XID order equals commit order; XIDs are assigned when transactions start.
Using an XID copied from another cluster or unrelated timeline.
Setting another recovery target selector at the same time.
Choosing inclusive without deciding whether the target transaction itself must be present.
Treating an XID as a globally unique business identifier across wraparound and clusters.
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_xid 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 2
- PG 18 → 19changed
- PG 11 → 12added
Related entries
Further reading
Definition snapshot: english-manuals:9d3bcbd0b0b19648cfbe0cd8d81… · English manual source