{"Entry":{"collection":"guc","key":"max_standby_archive_delay","name":"max_standby_archive_delay","aliases":[],"metadata":{"baseline":false,"boot_human":"Not specified","boot_val":null,"category":"Replication / Standby Servers","category_zh":"","changed_in":["9.1","18"],"changes":[{"documentation_changed":false,"fields":{},"from":"8.4","status":"added","to":"9.0"},{"documentation_changed":false,"fields":{"category":{"from":"Write-Ahead Log / Standby Servers","to":"Replication / Standby Servers"},"max_val":{"from":"2147483","to":"2147483647"}},"from":"9.0","status":"changed","to":"9.1"},{"documentation_changed":true,"fields":{},"from":"9.5","status":"changed","to":"9.6"},{"documentation_changed":true,"fields":{},"from":"11","status":"changed","to":"12"},{"documentation_changed":true,"fields":{},"from":"13","status":"changed","to":"14"},{"documentation_changed":true,"fields":{},"from":"14","status":"changed","to":"15"},{"documentation_changed":true,"fields":{},"from":"16","status":"changed","to":"17"},{"documentation_changed":false,"fields":{"extra_desc":{"from":null,"to":"-1 means wait forever."}},"from":"17","status":"changed","to":"18"}],"content_hash":"8c0a315992251d7d6436aa0c08202b56d0eaeda0909ec5c1f22c5c2e1bbe8d1d","context":"","default_changed_in":[],"default_history":[{"from":"9.0","to":"19","value":"30 s"}],"editorial":{"advice":{"olap":"Read standbys and logical subscribers often see long queries or large transactions. Put explicit bounds on replay/apply and monitor lag, worker saturation, slot restart_lsn, and conflict cancellations.","oltp":"Size max_standby_archive_delay from topology, failover roles, slot/subscription count, and reconnect headroom. Test worst-case primary latency, standby replay, and disk retention before production.","small":"Configure only replication capacity that is actually used. Even a small topology needs bounded timeouts and slot lifecycle; unlimited retention is not reliability."},"mechanism":["Sets the maximum delay before canceling queries when a hot standby server is processing archived WAL data. A configuration reload applies a new value; existing work already in flight is not retroactively changed.","While replaying WAL fetched from an archive, recovery may wait up to this accumulated delay for conflicting hot-standby queries before canceling them. It is measured against replay progress, not granted afresh to every query; -1 can let replay lag without bound.","Monitor and change max_standby_archive_delay together with max_standby_streaming_delay, hot_standby, hot_standby_feedback. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value."],"pitfalls":["Changing it on the wrong primary, standby, sender, or subscriber role.","Watching only configured bytes/time instead of actual lag, slot position, and worker state.","Failing over to a node that lacks the old primary's capacity or prerequisites.","Using infinite waits or WAL retention to hide a failed consumer."],"references":[{"title":"PostgreSQL 19 Beta 4: max_standby_archive_delay","url":"https://www.postgresql.org/docs/19/runtime-config-replication.html#GUC-MAX-STANDBY-ARCHIVE-DELAY"},{"title":"PostgreSQL 19 release notes","url":"https://www.postgresql.org/docs/19/release-19.html"}],"related":["max_standby_streaming_delay","hot_standby","hot_standby_feedback","recovery_min_apply_delay","primary_conninfo","primary_slot_name"],"summary":"max_standby_archive_delay — Sets the maximum delay before canceling queries when a hot standby server is processing archived WAL data. Observed in PG9.0–19 Beta 4; its last measured boot default is 30 s in PG19 Beta 4, with sighup context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA."},"enumvals":[],"first_version":"9.0","group":"Replication","group_slug":"replication","imported_at":"2026-09-27T17:57:31.746805+08:00","intro_commit":{},"key":"max_standby_archive_delay","last_version":"20","max_val":"","min_val":"","name":"max_standby_archive_delay","position":285,"present_in":["9.0","9.1","9.2","9.3","9.4","9.5","9.6","10","11","12","13","14","15","16","17","18","19","20"],"short_desc":"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 Section 26.4.2.","short_desc_zh":"","source_rev":"english-manuals:91c161855c89d451e3ab3d87d18ca5dc921dc565d1cb4e8a0fcbc8a33b83cff3","unit":"","vartype":"integer"}},"Definition":{"Collection":"guc","Key":"max_standby_archive_delay","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"max_standby_archive_delay","SourceRevision":"english-manuals:91c161855c89d451e3ab3d87d18ca5dc921dc565d1cb4e8a0fcbc8a33b83cff3","Facts":{"boot_val":"30000","category":"Replication / Standby Servers","context":"sighup","description":"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 Section 26.4.2. 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.","doc":{"anchor":"GUC-MAX-STANDBY-ARCHIVE-DELAY","file":"runtime-config-replication.html","lang":"en","sha256":"c78480a202f8579e2655e080060afe4859c9eb26a16318fb9099dabb178fb32d","slug":"18"},"documented":true,"enumvals":null,"extra_desc":"-1 means wait forever.","lang":"en","max_val":"2147483647","metadata_version":"18","min_val":"-1","name":"max_standby_archive_delay","short_desc":"Sets the maximum delay before canceling queries when a hot standby server is processing archived WAL data.","source":"pg-settings-source-snapshot","unit":"ms","vartype":"integer"},"ManualEvidence":{"doc":{"anchor":"GUC-MAX-STANDBY-ARCHIVE-DELAY","file":"runtime-config-replication.html","lang":"en","sha256":"c78480a202f8579e2655e080060afe4859c9eb26a16318fb9099dabb178fb32d","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"max_standby_archive_delay","SourceDatabase":"pgweb","Version":"18","Locale":"zh-Hans","Title":"max_standby_archive_delay","Summary":"","BodyHTML":"\u003cp\u003e当热备处于活动状态时，此参数确定备库在取消与即将应用的WAL条目冲突的备库查询之前应等待多长时间，如\u003ca href=\"/docs/18/hot-standby.html#HOT-STANDBY-CONFLICT\" rel=\"nofollow\"\u003e第 26.4.2 节\u003c/a\u003e中所述。\u003ccode\u003emax_standby_archive_delay\u003c/code\u003e在从WAL归档中读取WAL数据时适用（因此不是当前的）。如果未指定单位，则将其视为毫秒。默认值为30秒。值为-1允许备库永远等待冲突查询完成。此参数只能在\u003ccode\u003epostgresql.conf\u003c/code\u003e文件或服务器命令行中设置。\u003c/p\u003e\u003cp\u003e注意，\u003ccode\u003emax_standby_archive_delay\u003c/code\u003e并不等同于查询在被取消前可以运行的最长时间；它表示应用任意一个 WAL 段的数据所允许的最长总时间。因此，如果某个查询先前在处理该 WAL 段时已造成显著延迟，后续冲突查询的宽限时间就会短得多。\u003c/p\u003e","SourceRevision":"2026-09-11@29c86d9","ContentHash":"9128d01d8ffc19580bbb9e52bf745e21cf7835826b35c72fab1ebcf8e7af32c6","Payload":{"carried_from":"","carry_reason":"","doc_html":"\u003cp\u003e当热备处于活动状态时，此参数确定备库在取消与即将应用的WAL条目冲突的备库查询之前应等待多长时间，如\u003ca href=\"/docs/18/hot-standby.html#HOT-STANDBY-CONFLICT\" title=\"26.4.2. 处理查询冲突\"\u003e第 26.4.2 节\u003c/a\u003e中所述。\u003ccode class=\"varname\"\u003emax_standby_archive_delay\u003c/code\u003e在从WAL归档中读取WAL数据时适用（因此不是当前的）。如果未指定单位，则将其视为毫秒。默认值为30秒。值为-1允许备库永远等待冲突查询完成。此参数只能在\u003ccode class=\"filename\"\u003epostgresql.conf\u003c/code\u003e文件或服务器命令行中设置。\u003c/p\u003e\u003cp\u003e注意，\u003ccode class=\"varname\"\u003emax_standby_archive_delay\u003c/code\u003e并不等同于查询在被取消前可以运行的最长时间；它表示应用任意一个 WAL 段的数据所允许的最长总时间。因此，如果某个查询先前在处理该 WAL 段时已造成显著延迟，后续冲突查询的宽限时间就会短得多。\u003c/p\u003e","doc_same_as":""}},"RequestedLocale":"zh-Hans","Fallback":false,"Versions":["10","11","12","13","14","15","16","17","18","19","20","9.0","9.1","9.2","9.3","9.4","9.5","9.6"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}