By default, a standby server restores WAL records from the sending server as soon as possible.
At a glance
| Property | Value |
|---|---|
| Parameter | recovery_min_apply_delay |
| Category | Replication |
| Default | zero |
| Value type | integer |
| Change scope | Per-session (SET) |
| Available in | PostgreSQL 12, 13, 14, 15, 16, 17, 18, 19 (added in 12) |
What it does
By default, a standby server restores WAL records from the sending server as soon as possible. It may be useful to have a time-delayed copy of the data, offering opportunities to correct data loss errors. This parameter allows you to delay recovery by a specified amount of time. For example, if you set this parameter to 5min, the standby will replay each transaction commit only when the system time on the standby is at least five minutes past the commit time reported by the primary. If this value is specified without units, it is taken as milliseconds. The default is zero, adding no delay.
It is possible that the replication delay between servers exceeds the value of this parameter, in which case no delay is added. Note that the delay is calculated between the WAL time stamp as written on primary and the current time on the standby. Delays in transfer because of network lag or cascading replication configurations may reduce the actual wait time significantly. If the system clocks on primary and standby are not synchronized, this may lead to recovery applying records earlier than expected; but that is not a major issue because useful settings of this parameter are much larger than typical time deviations between servers.
(Description quoted from the official PostgreSQL documentation.)
How to apply a change
Can be set per session with SET, per role/database with ALTER ROLE/DATABASE ... SET, or globally in postgresql.conf.
Inspect the current value and source with SHOW recovery_min_apply_delay; or SELECT name, setting, unit, context, source FROM pg_settings WHERE name = 'recovery_min_apply_delay';.
Tuning guidance
Set it to keep a standby deliberately behind (e.g. 1h) as a human-error safety net for PITR-style recovery; it increases failover lag by exactly this delay, so it is a DR tool, not an HA one.