{"Entry":{"collection":"guc","key":"max_standby_streaming_delay","name":"max_standby_streaming_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"},{"documentation_changed":true,"fields":{},"from":"18","status":"changed","to":"19"}],"content_hash":"f333f41b98bda0aa289b7d1581732247b1345f345fb36d64be5a912d4333f284","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_streaming_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 streamed WAL data. A configuration reload applies a new value; existing work already in flight is not retroactively changed.","While replaying streamed WAL, recovery may wait up to this accumulated delay for conflicting queries before cancellation. Larger values favor read continuity but raise replication lag and recovery-point exposure; hot_standby_feedback addresses some snapshot conflicts with primary-side bloat risk.","Monitor and change max_standby_streaming_delay together with max_standby_archive_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_streaming_delay","url":"https://www.postgresql.org/docs/19/runtime-config-replication.html#GUC-MAX-STANDBY-STREAMING-DELAY"},{"title":"PostgreSQL 19 release notes","url":"https://www.postgresql.org/docs/19/release-19.html"}],"related":["max_standby_archive_delay","hot_standby","hot_standby_feedback","recovery_min_apply_delay","in_hot_standby","primary_conninfo"],"summary":"max_standby_streaming_delay — Sets the maximum delay before canceling queries when a hot standby server is processing streamed 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.75088+08:00","intro_commit":{},"key":"max_standby_streaming_delay","last_version":"20","max_val":"","min_val":"","name":"max_standby_streaming_delay","position":286,"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:faa82c7cccdcaff85aa48eb39b7a0147e90e1f38256c6eea9891100922a2ab14","unit":"","vartype":"integer"}},"Definition":{"Collection":"guc","Key":"max_standby_streaming_delay","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"max_standby_streaming_delay","SourceRevision":"english-manuals:faa82c7cccdcaff85aa48eb39b7a0147e90e1f38256c6eea9891100922a2ab14","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_streaming_delay applies when WAL data is being received via streaming replication. 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_streaming_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 WAL data once it has been received from the primary server. Thus, if one query has resulted in significant delay, subsequent conflicting queries will have much less grace time until the standby server has caught up again.","doc":{"anchor":"GUC-MAX-STANDBY-STREAMING-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_streaming_delay","short_desc":"Sets the maximum delay before canceling queries when a hot standby server is processing streamed WAL data.","source":"pg-settings-source-snapshot","unit":"ms","vartype":"integer"},"ManualEvidence":{"doc":{"anchor":"GUC-MAX-STANDBY-STREAMING-DELAY","file":"runtime-config-replication.html","lang":"en","sha256":"c78480a202f8579e2655e080060afe4859c9eb26a16318fb9099dabb178fb32d","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"max_standby_streaming_delay","SourceDatabase":"pgweb","Version":"18","Locale":"zh-Hans","Title":"max_standby_streaming_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_streaming_delay\u003c/code\u003e在通过流复制接收WAL数据时应用。如果未指定单位，则将其视为毫秒。默认值为30秒。值为-1允许备库永远等待冲突查询完成。此参数只能在\u003ccode\u003epostgresql.conf\u003c/code\u003e文件或服务器命令行中设置。\u003c/p\u003e\u003cp\u003e注意，\u003ccode\u003emax_standby_streaming_delay\u003c/code\u003e并不等同于查询在被取消前可以运行的最长时间；它表示从主库接收到 WAL 数据后，允许用于应用这些数据的最长总时间。因此，如果某个查询已造成显著延迟，后续冲突查询的宽限时间就会短得多，直到备库再次赶上进度。\u003c/p\u003e","SourceRevision":"2026-09-11@29c86d9","ContentHash":"4e5d73da2ba51ea114fec1fb8f944869d0cbd833d557a615b3435ee493ed65d2","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_streaming_delay\u003c/code\u003e在通过流复制接收WAL数据时应用。如果未指定单位，则将其视为毫秒。默认值为30秒。值为-1允许备库永远等待冲突查询完成。此参数只能在\u003ccode class=\"filename\"\u003epostgresql.conf\u003c/code\u003e文件或服务器命令行中设置。\u003c/p\u003e\u003cp\u003e注意，\u003ccode class=\"varname\"\u003emax_standby_streaming_delay\u003c/code\u003e并不等同于查询在被取消前可以运行的最长时间；它表示从主库接收到 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}