Parameter · Replication / Standby Servers
max_standby_archive_delay
Sets the maximum delay before canceling queries when a hot standby server is processing archived WAL data. -1 means wait forever.
- Default:
30s - Type: integer (ms)
- Range: -1 … max (2147483647)
- Applies: Reload
In plain words
Same idea as max_standby_streaming_delay, but for WAL the standby reads from the archive with restore_command (for example while catching up after a long outage). It caps how long replay may wait for conflicting read queries before cancelling them.
-1 waits forever; 0 cancels immediately.
For DBAs and operators
For archive WAL the clock starts when the segment file was restored, so the grace for one file is this value minus the time already spent replaying it. Whole segments arrive at once, so replay is bursty and conflicts may cluster.
The cancellation messages and the counters in pg_stat_database_conflicts are the same as for streaming:
ERROR: canceling statement due to conflict with recovery
DETAIL: User was holding a relation lock for too long.
Usually set equal to max_standby_streaming_delay. On a standby that relies on the archive (log shipping only), weigh replay lag against cancelled reporting queries, as for streaming.
How to change it
Change in postgresql.conf or ALTER SYSTEM, then run SELECT pg_reload_conf().
See it in context
Hot standby and recovery conflicts Archiving and point-in-time recovery Startup process
Related parameters
max_standby_streaming_delay restore_command hot_standby_feedback hot_standby