{"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"}],"derived_content_hash":"c6171afa33609a3de18709a78b722184f9f190d236a8d113c757c62724e21372","documentation_refresh":{"batch":"20261113","original_source_rev":"wiki-repair-20261023:614fb0942dd91fa7a15c36a9b589b71b0fb62bc79593e14bbfdbc9327efa9ac8","versions":{"14":"14.25","15":"15.20","16":"16.16","17":"17.12","18":"18.7","19":"19rc2"}},"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"],"repair_provenance":{"original_source_revision":"english-manuals:91c161855c89d451e3ab3d87d18ca5dc921dc565d1cb4e8a0fcbc8a33b83cff3","receipt_sha256":"91a60d0f21ddf02806f905dd5d02dbf233ccf0deea874f2a75c1b8b551648d1f","repair":"wiki-repair-20261023"},"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":"wiki-repair-20261023:614fb0942dd91fa7a15c36a9b589b71b0fb62bc79593e14bbfdbc9327efa9ac8","unit":"","vartype":"integer"}},"Definition":{"Collection":"guc","Key":"max_standby_archive_delay","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"max_standby_archive_delay","SourceRevision":"wiki-repair-20261023:614fb0942dd91fa7a15c36a9b589b71b0fb62bc79593e14bbfdbc9327efa9ac8","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.","description_zh":"当热备处于活动状态时，此参数确定备库在取消与即将应用的 WAL 条目冲突的备库查询之前应等待多长时间，如第 26.4.2 节中所述。max_standby_archive_delay 在从 WAL 归档中读取 WAL 数据时适用（因此不是当前的）。如果未指定单位，则将其视为毫秒。默认值为 30 秒。值为-1 允许备库永远等待冲突查询完成。此参数只能在 postgresql.conf 文件或服务器命令行中设置。 注意，max_standby_archive_delay 并不等同于查询在被取消前可以运行的最长时间；它表示应用任意一个 WAL 段的数据所允许的最长总时间。因此，如果某个查询先前在处理该 WAL 段时已造成显著延迟，后续冲突查询的宽限时间就会短得多。","description_zh_html":"\u003cp\u003e\n        当热备处于活动状态时，此参数确定备库在取消与即将应用的 WAL 条目冲突的备库查询之前应等待多长时间，如\u003ca class=\"xref\" href=\"/zh/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 文件或服务器命令行中设置。\n       \u003c/p\u003e\u003cp\u003e注意，\u003ccode class=\"varname\"\u003emax_standby_archive_delay\u003c/code\u003e 并不等同于查询在被取消前可以运行的最长时间；它表示应用任意一个 WAL 段的数据所允许的最长总时间。因此，如果某个查询先前在处理该 WAL 段时已造成显著延迟，后续冲突查询的宽限时间就会短得多。\u003c/p\u003e","doc":{"anchor":"GUC-MAX-STANDBY-ARCHIVE-DELAY","file":"runtime-config-replication.html","lang":"en","sha256":"c0b8bd86131ec62d4df97ce480d004aa7e3544477d053f0c2d4047b9edad5cc0","slug":"18"},"doc_html":"\u003cp\u003e\n        When hot standby is active, this parameter determines how long the\n        standby server should wait before canceling standby queries that\n        conflict with about-to-be-applied WAL entries, as described in\n        \u003ca class=\"xref\" href=\"/docs/18/hot-standby.html#HOT-STANDBY-CONFLICT\" title=\"26.4.2. Handling Query Conflicts\"\u003eSection 26.4.2\u003c/a\u003e.\n        \u003ccode class=\"varname\"\u003emax_standby_archive_delay\u003c/code\u003e applies when WAL data is\n        being read from WAL archive (and is therefore not current).\n        If this value is specified without units, it is taken as milliseconds.\n        The default is 30 seconds.\n        A value of -1 allows the standby to wait forever for conflicting\n        queries to complete.\n        This parameter can only be set in the \u003ccode class=\"filename\"\u003epostgresql.conf\u003c/code\u003e\n        file or on the server command line.\n       \u003c/p\u003e\u003cp\u003e\n        Note that \u003ccode class=\"varname\"\u003emax_standby_archive_delay\u003c/code\u003e is not the same as the\n        maximum length of time a query can run before cancellation; rather it\n        is the maximum total time allowed to apply any one WAL segment's data.\n        Thus, if one query has resulted in significant delay earlier in the\n        WAL segment, subsequent conflicting queries will have much less grace\n        time.\n       \u003c/p\u003e","doc_same_as":"","documentation_revision":{"inputs":[{"file":"runtime-config-replication.html","kind":"same-version-reviewed-manual","locale":"en","sha256":"c0b8bd86131ec62d4df97ce480d004aa7e3544477d053f0c2d4047b9edad5cc0","version":"18.7"},{"file":"runtime-config-replication.html","kind":"same-version-reviewed-manual","locale":"zh-Hans","sha256":"83907b5f469e979a7b9ec875b5e7bdaa2ef6b85596ca31b45174f68cd7398b18","version":"18.7"}],"release":"18.7","runtime_remeasured":false,"source_revision":"pgdoc:b9f0e7232f60f380d642ac9b99226606c254b552"},"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","translation_provenance":{"inputs":[{"kind":"current-pgdoc-translation","path":"/Users/vonng/pgsty/pgdoc/zh/18/html/runtime-config-replication.html","sha256":"52bd5892f7e5511d05f46fc0c13a017de85307c674a9014948eb4ad480326c15"}],"kind":"same-version-pgdoc","locale":"zh-Hans","source_revision":"b1b500221dbe5437cfca004d6b04d3f6e422765d","version":"18"},"unit":"ms","vartype":"integer","zh_from":"same-version-manual"},"ManualEvidence":{"doc":{"anchor":"GUC-MAX-STANDBY-ARCHIVE-DELAY","file":"runtime-config-replication.html","lang":"en","sha256":"c0b8bd86131ec62d4df97ce480d004aa7e3544477d053f0c2d4047b9edad5cc0","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"max_standby_archive_delay","SourceDatabase":"center","Version":"18","Locale":"en","Title":"max_standby_archive_delay","Summary":"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.","BodyHTML":"\u003cp\u003e\n        When hot standby is active, this parameter determines how long the\n        standby server should wait before canceling standby queries that\n        conflict with about-to-be-applied WAL entries, as described in\n        \u003ca href=\"/docs/18/hot-standby.html#HOT-STANDBY-CONFLICT\" rel=\"nofollow\"\u003eSection 26.4.2\u003c/a\u003e.\n        \u003ccode\u003emax_standby_archive_delay\u003c/code\u003e applies when WAL data is\n        being read from WAL archive (and is therefore not current).\n        If this value is specified without units, it is taken as milliseconds.\n        The default is 30 seconds.\n        A value of -1 allows the standby to wait forever for conflicting\n        queries to complete.\n        This parameter can only be set in the \u003ccode\u003epostgresql.conf\u003c/code\u003e\n        file or on the server command line.\n       \u003c/p\u003e\u003cp\u003e\n        Note that \u003ccode\u003emax_standby_archive_delay\u003c/code\u003e is not the same as the\n        maximum length of time a query can run before cancellation; rather it\n        is the maximum total time allowed to apply any one WAL segment\u0026#39;s data.\n        Thus, if one query has resulted in significant delay earlier in the\n        WAL segment, subsequent conflicting queries will have much less grace\n        time.\n       \u003c/p\u003e","SourceRevision":"wiki-repair-20261023:614fb0942dd91fa7a15c36a9b589b71b0fb62bc79593e14bbfdbc9327efa9ac8","ContentHash":"f1c42516358b0439860096e84e6deffe1fd47f43071d49dcb549b0ff3e0f3db4","Payload":{"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."}},"RequestedLocale":"en","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}