Type: | integer |
Default: | 30000 (30s) |
Min: | -1 (-1) |
Max: | 2147483647 (2147483647ms) |
Unit: | milliseconds (ms) |
Context: | sighup |
Restart: | false |
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.
Recommendations
On StackOverflow
- How to modify the max_standby_archive_delay parameter on AWS RDS instance?
- Manage conflicts and lag on Postgres Replication in Hot Standby with read heavy Slave
- Postgres Hot Standby and Long Running Queries On Slave
- PostgreSQL: canceling statement due to conflict with recovery
- What causes data on a read-replica to be an old_snapshot and cause conflict?