recovery_end_command

Definition PG 18 manual

This parameter specifies a shell command that will be executed once only at the end of recovery. This parameter is optional. The purpose of the recovery_end_command is to provide a mechanism for cleanup following replication or recovery. Any %r is replaced by the name of the file containing the last valid restart point, like in archive_cleanup_command.

If the command returns a nonzero exit status then a warning log message will be written and the database will proceed to start up anyway. An exception is that if the command was terminated by a signal or an error by the shell (such as command not found), the database will not proceed with startup.

This parameter can only be set in the postgresql.conf file or on the server command line.

How it works

Sets the shell command that will be executed once at the end of recovery. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

PostgreSQL runs this shell command once when archive recovery finishes or a standby is promoted. %r expands to the last restart-point file name; command failure is logged but must not be treated as a transactional post-promotion hook.

Monitor and change recovery_end_command together with archive_mode, archive_command, archive_library. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Operational considerations

Treating the shell command as a transactional promotion hook whose failure rolls recovery back.

Misreading %r and deleting WAL still needed by another recovery consumer.

Using non-idempotent external side effects without accounting for promotion and recovery retries.

Assuming a reload executes the command; it runs once when archive recovery ends.

Embedding credentials or unsafe shell expansion in a command executed by the PostgreSQL service account.

Workload guidance

OLAP: Provision archive throughput and capacity for bulk-load WAL peaks. If archiving falls behind, throttle the job and alert; never hide backlog with false success or aggressive cleanup.

OLTP: Manage recovery_end_command as part of the backup/restore protocol: the command or module must be idempotent, fail visibly, and be verified by restoring from the real archive—not merely by exit status.

SMALL: Enable it only for a defined PITR requirement and use a mature backup tool. Keep rebuildable instances simple, but never install a no-op command that creates the illusion of a backup.