Parameter · Replication / Standby Servers
recovery_min_apply_delay
Sets the minimum delay for applying changes during recovery.
- Default:
0 - Type: integer (ms)
- Range: 0 … max (2147483647)
- Applies: Reload
In plain words
A delayed standby receives WAL immediately but waits before applying each commit, so it always shows the database as it was, say, one hour ago. If someone drops a table by mistake on the primary, you have an hour to stop replay on the delayed standby and copy the data back.
Default 0: no delay.
For DBAs and operators
Only commit records are delayed: replay of a commit waits until the standby's clock is at least this far past the primary's commit timestamp. Other records replay until they hit the next delayed commit. The delay starts once the standby reaches a consistent state and is skipped in crash recovery and once promotion is triggered. Clock skew between servers shifts the effective delay.
- Received WAL waits in the standby's
pg_wal, so plan for delay × WAL rate of extra disk. - To rescue data:
SELECT pg_wal_replay_pause();quickly, then set arecovery_target_*and restart, or query the paused standby. - With
synchronous_commit = remote_applyand this standby as synchronous, every commit would wait for the delay: never do that. - Feedback (
hot_standby_feedback) is delayed too, which can mean extra bloat on the primary.
SELECT now() - pg_last_xact_replay_timestamp() AS replay_delay;Waiting standby startup process shows wait_event = 'RecoveryApplyDelay'.
How to change it
Change in postgresql.conf or ALTER SYSTEM, then run SELECT pg_reload_conf().
See it in context
Startup process Streaming replication Archiving and point-in-time recovery WAL receiver Hot standby and recovery conflicts
Related parameters
max_standby_streaming_delay hot_standby_feedback synchronous_commit recovery_target_time