{"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"}],"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"],"short_desc":"Terminate replication connections that are inactive for longer than this amount of time.","short_desc_zh":"","source_rev":"english-manuals:5fd62ce2e7d993b7383710fa6dc798f1421ec25c6f1e6b0d53761a570d34d940","unit":"","vartype":"integer"}},"Definition":{"Collection":"guc","Key":"wal_sender_timeout","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"wal_sender_timeout","SourceRevision":"english-manuals:5fd62ce2e7d993b7383710fa6dc798f1421ec25c6f1e6b0d53761a570d34d940","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.","doc":{"anchor":"GUC-WAL-SENDER-TIMEOUT","file":"runtime-config-replication.html","lang":"en","sha256":"c78480a202f8579e2655e080060afe4859c9eb26a16318fb9099dabb178fb32d","slug":"18"},"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","unit":"ms","vartype":"integer"},"ManualEvidence":{"doc":{"anchor":"GUC-WAL-SENDER-TIMEOUT","file":"runtime-config-replication.html","lang":"en","sha256":"c78480a202f8579e2655e080060afe4859c9eb26a16318fb9099dabb178fb32d","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\u003eTerminate 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.\u003c/p\u003e","SourceRevision":"english-manuals:5fd62ce2e7d993b7383710fa6dc798f1421ec25c6f1e6b0d53761a570d34d940","ContentHash":"7dbd1ffa0daa4f9782284cd46bd30a6f0f82156f5ee7a090040c9824d6e96947","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":"zh-Hans","Fallback":true,"Versions":["10","11","12","13","14","15","16","17","18","19","20","9.3","9.4","9.5","9.6"],"Locales":["en"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}