recovery_target_action

Definition PG 18 manual

Specifies what action the server should take once the recovery target is reached. The default is pause, which means recovery will be paused. promote means the recovery process will finish and the server will start to accept connections. Finally shutdown will stop the server after reaching the recovery target.

The intended use of the pause setting is to allow queries to be executed against the database to check if this recovery target is the most desirable point for recovery. The paused state can be resumed by using pg_wal_replay_resume() (see Table 9.99), which then causes recovery to end. If this recovery target is not the desired stopping point, then shut down the server, change the recovery target settings to a later target and restart to continue recovery.

The shutdown setting is useful to have the instance ready at the exact replay point desired. The instance will still be able to replay more WAL records (and in fact will have to replay WAL records since the last checkpoint next time it is started).

Note that because recovery.signal will not be removed when recovery_target_action is set to shutdown, any subsequent start will end with immediate shutdown unless the configuration is changed or the recovery.signal file is removed manually.

This setting has no effect if no recovery target is set. If hot_standby is not enabled, a setting of pause will act the same as shutdown. If the recovery target is reached while a promotion is ongoing, a setting of pause will act the same as promote.

In any case, if a recovery target is configured but the archive recovery ends before the target is reached, the server will shut down with a fatal error.

How it works

Selects what PostgreSQL does after it reaches a configured recovery target. The value is read when recovery starts.

pause leaves recovery paused for inspection, promote ends recovery and opens the server for normal service, and shutdown stops the server at the target. pause requires hot_standby for query inspection.

The setting has no effect without a stopping target. With shutdown, recovery.signal is not removed, so an unchanged restart reaches the target and shuts down again; remove or change the recovery configuration deliberately after validation.

Operational considerations

Expecting an action when no stopping target is configured.

Using pause with hot_standby disabled and expecting to inspect the database with queries.

Using promote before the recovered state has been verified.

Using shutdown and restarting with recovery.signal and the same target still present.

Treating shutdown as permanent removal of later WAL; the next start still replays from the last checkpoint to the target.

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_action 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.