When hot standby is active, this parameter determines how long the standby server should wait before canceling standby queries that conflict with about-to-be-applied WAL entries, as described in hot_standby_conflict.
At a glance
| Property | Value |
|---|---|
| Parameter | max_standby_archive_delay |
| Category | Replication |
| Default | 30 |
| Value type | integer |
| Change scope | Reload (postgresql.conf, SIGHUP) |
| Available in | PostgreSQL 12, 13, 14, 15, 16, 17, 18, 19 (added in 12) |
What it does
When hot standby is active, this parameter determines how long the standby server should wait before canceling standby queries that conflict with about-to-be-applied WAL entries, as described in hot_standby_conflict. max_standby_archive_delay applies when WAL data is being read from WAL archive (and is therefore not current). If this value is specified without units, it is taken as milliseconds. The default is 30 seconds. A value of -1 allows the standby to wait forever for conflicting queries to complete. This parameter can only be set in the postgresql.conf file or on the server command line.
Note that max_standby_archive_delay is not the same as the maximum length of time a query can run before cancellation; rather it is the maximum total time allowed to apply any one WAL segment’s data. Thus, if one query has resulted in significant delay earlier in the WAL segment, subsequent conflicting queries will have much less grace time.
(Description quoted from the official PostgreSQL documentation.)
How to apply a change
Set it in postgresql.conf (or with ALTER SYSTEM) and reload with SELECT pg_reload_conf(); or pg_ctl reload — no restart needed.
Inspect the current value and source with SHOW max_standby_archive_delay; or SELECT name, setting, unit, context, source FROM pg_settings WHERE name = 'max_standby_archive_delay';.
Tuning guidance
This parameter is rarely a performance lever. Leave it at the default unless you have a specific, documented reason to change it, change it on one session or one role/database first, and confirm the effect with pg_settings and your own measurements before rolling it out cluster-wide.