{"Entry":{"collection":"guc","key":"wal_sender_timeout","name":"wal_sender_timeout","aliases":[],"metadata":{"baseline":false,"boot_human":"Not specified","boot_val":null,"category":"Replication / Sending Servers","category_zh":"","changed_in":["12","19"],"changes":[{"documentation_changed":false,"fields":{},"from":"9.2","status":"added","to":"9.3"},{"documentation_changed":true,"fields":{"context":{"from":"sighup","to":"user"}},"from":"11","status":"changed","to":"12"},{"documentation_changed":false,"fields":{"extra_desc":{"from":null,"to":"0 disables the timeout."}},"from":"18","status":"changed","to":"19"}],"content_hash":"11e53a4e20a1a5732254bd5abfb172fa581e28dc7a994244bf5512a2dbf28b8c","context":"","default_changed_in":[],"default_history":[{"from":"9.3","to":"19","value":"1 min"}],"derived_content_hash":"3a8f5973da3c6533545e32406d14160770202a73138d766ddc077d1281d87b95","documentation_refresh":{"batch":"20261113","original_source_rev":"wiki-repair-20261023:dafb840a49c7760c8449c9029a95fa1264451198d04475565dd199b3ce9a6a51","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 wal_sender_timeout 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 time to wait for WAL replication. It can be changed at session scope, so different sessions may observe different behavior.","A WAL sender terminates a replication connection that remains inactive for this interval. Each sender session may use a location-appropriate value; zero disables detection and very short settings cause churn across high-latency links.","Monitor and change wal_sender_timeout together with max_wal_senders, max_replication_slots, wal_level. Validate on the relevant server role and real workload, then use its user 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: wal_sender_timeout","url":"https://www.postgresql.org/docs/19/runtime-config-replication.html#GUC-WAL-SENDER-TIMEOUT"},{"title":"PostgreSQL 19 release notes","url":"https://www.postgresql.org/docs/19/release-19.html"}],"related":["max_wal_senders","max_replication_slots","wal_level","primary_conninfo","max_slot_wal_keep_size","wal_receiver_status_interval"],"summary":"wal_sender_timeout — Sets the maximum time to wait for WAL replication. Observed in PG9.3–19 Beta 4; its last measured boot default is 1 min in PG19 Beta 4, with user context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA."},"enumvals":[],"first_version":"9.3","group":"Replication","group_slug":"replication","imported_at":"2026-09-27T17:57:32.370214+08:00","intro_commit":{"authored_at":"2012-10-11T17:39:52+03:00","discussion":[],"hash":"6f60fdd7015b032bf49273c99f80913d57eac284","subject":"Improve replication connection timeouts.","url":"https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=6f60fdd7015b032bf49273c99f80913d57eac284"},"key":"wal_sender_timeout","last_version":"20","max_val":"","min_val":"","name":"wal_sender_timeout","position":481,"present_in":["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:5fd62ce2e7d993b7383710fa6dc798f1421ec25c6f1e6b0d53761a570d34d940","receipt_sha256":"2aaaf087bb4c596e0b7a509e0e0c0e4fa6c0d3babbbadfeb6a1a27666b4629cf","repair":"wiki-repair-20261023"},"short_desc":"Terminate replication connections that are inactive for longer than this amount of time.","short_desc_zh":"","source_rev":"wiki-repair-20261023:dafb840a49c7760c8449c9029a95fa1264451198d04475565dd199b3ce9a6a51","unit":"","vartype":"integer"}},"Definition":{"Collection":"guc","Key":"wal_sender_timeout","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"wal_sender_timeout","SourceRevision":"wiki-repair-20261023:dafb840a49c7760c8449c9029a95fa1264451198d04475565dd199b3ce9a6a51","Facts":{"boot_val":"60000","category":"Replication / Sending Servers","context":"user","description":"Terminate replication connections that are inactive for longer than this amount of time. This is useful for the sending server to detect a standby crash or network outage. If this value is specified without units, it is taken as milliseconds. The default value is 60 seconds. A value of zero disables the timeout mechanism. With a cluster distributed across multiple geographic locations, using different values per location brings more flexibility in the cluster management. A smaller value is useful for faster failure detection with a standby having a low-latency network connection, and a larger value helps in judging better the health of a standby if located on a remote location, with a high-latency network connection.","description_zh":"终止非活动时间超过此值的复制连接。这有助于发送服务器检测备库崩溃或网络中断。如果指定值时没有单位，则按毫秒计算。默认值为 60 秒。值零禁用超时机制。 对于跨多个地理位置分布的集簇，在各位置使用不同的值可以提高集簇管理的灵活性。对于网络延迟较低的备库，较小的值有助于更快地检测故障；对于地处远端、网络延迟较高的备库，较大的值有助于更准确地判断其健康状况。","description_zh_html":"\u003cp\u003e\n        终止非活动时间超过此值的复制连接。这有助于发送服务器检测备库崩溃或网络中断。如果指定值时没有单位，则按毫秒计算。默认值为 60 秒。值零禁用超时机制。\n       \u003c/p\u003e\u003cp\u003e\n        对于跨多个地理位置分布的集簇，在各位置使用不同的值可以提高集簇管理的灵活性。对于网络延迟较低的备库，较小的值有助于更快地检测故障；对于地处远端、网络延迟较高的备库，较大的值有助于更准确地判断其健康状况。\n       \u003c/p\u003e","doc":{"anchor":"GUC-WAL-SENDER-TIMEOUT","file":"runtime-config-replication.html","lang":"en","sha256":"c0b8bd86131ec62d4df97ce480d004aa7e3544477d053f0c2d4047b9edad5cc0","slug":"18"},"doc_html":"\u003cp\u003e\n        Terminate replication connections that are inactive for longer\n        than this amount of time. This is useful for\n        the sending server to detect a standby crash or network outage.\n        If this value is specified without units, it is taken as milliseconds.\n        The default value is 60 seconds.\n        A value of zero disables the timeout mechanism.\n       \u003c/p\u003e\u003cp\u003e\n        With a cluster distributed across multiple geographic\n        locations, using different values per location brings more flexibility\n        in the cluster management. A smaller value is useful for faster\n        failure detection with a standby having a low-latency network\n        connection, and a larger value helps in judging better the health\n        of a standby if located on a remote location, with a high-latency\n        network connection.\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":null,"lang":"en","max_val":"2147483647","metadata_version":"18","min_val":"0","name":"wal_sender_timeout","short_desc":"Sets the maximum time to wait for WAL replication.","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-WAL-SENDER-TIMEOUT","file":"runtime-config-replication.html","lang":"en","sha256":"c0b8bd86131ec62d4df97ce480d004aa7e3544477d053f0c2d4047b9edad5cc0","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"wal_sender_timeout","SourceDatabase":"center","Version":"18","Locale":"en","Title":"wal_sender_timeout","Summary":"Terminate replication connections that are inactive for longer than this amount of time. This is useful for the sending server to detect a standby crash or network outage. If this value is specified without units, it is taken as milliseconds. The default value is 60 seconds. A value of zero disables the timeout mechanism. With a cluster distributed across multiple geographic locations, using different values per location brings more flexibility in the cluster management. A smaller value is useful for faster failure detection with a standby having a low-latency network connection, and a larger value helps in judging better the health of a standby if located on a remote location, with a high-latency network connection.","BodyHTML":"\u003cp\u003e\n        Terminate replication connections that are inactive for longer\n        than this amount of time. This is useful for\n        the sending server to detect a standby crash or network outage.\n        If this value is specified without units, it is taken as milliseconds.\n        The default value is 60 seconds.\n        A value of zero disables the timeout mechanism.\n       \u003c/p\u003e\u003cp\u003e\n        With a cluster distributed across multiple geographic\n        locations, using different values per location brings more flexibility\n        in the cluster management. A smaller value is useful for faster\n        failure detection with a standby having a low-latency network\n        connection, and a larger value helps in judging better the health\n        of a standby if located on a remote location, with a high-latency\n        network connection.\n       \u003c/p\u003e","SourceRevision":"wiki-repair-20261023:dafb840a49c7760c8449c9029a95fa1264451198d04475565dd199b3ce9a6a51","ContentHash":"f071f6d20c4477e0145b1b2805d191eee3d638b525bf512afbb42fe049a10851","Payload":{"description":"Terminate replication connections that are inactive for longer than this amount of time. This is useful for the sending server to detect a standby crash or network outage. If this value is specified without units, it is taken as milliseconds. The default value is 60 seconds. A value of zero disables the timeout mechanism. With a cluster distributed across multiple geographic locations, using different values per location brings more flexibility in the cluster management. A smaller value is useful for faster failure detection with a standby having a low-latency network connection, and a larger value helps in judging better the health of a standby if located on a remote location, with a high-latency network connection."}},"RequestedLocale":"en","Fallback":false,"Versions":["10","11","12","13","14","15","16","17","18","19","20","9.3","9.4","9.5","9.6"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}