{"Entry":{"collection":"guc","key":"wal_receiver_timeout","name":"wal_receiver_timeout","aliases":[],"metadata":{"baseline":false,"boot_human":"Not specified","boot_val":null,"category":"Replication / Standby Servers","category_zh":"","changed_in":["12","18","19"],"changes":[{"documentation_changed":false,"fields":{},"from":"9.2","status":"added","to":"9.3"},{"documentation_changed":true,"fields":{"short_desc":{"from":"Sets the maximum wait time to receive data from the primary.","to":"Sets the maximum wait time to receive data from the sending server."}},"from":"11","status":"changed","to":"12"},{"documentation_changed":false,"fields":{"extra_desc":{"from":null,"to":"0 disables the timeout."}},"from":"17","status":"changed","to":"18"},{"documentation_changed":true,"fields":{"context":{"from":"sighup","to":"user"}},"from":"18","status":"changed","to":"19"}],"content_hash":"35216ccca756dced16a42ec9ddef9c2ece5610b8b8a7198bf90ee4b7459e7d6f","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_receiver_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 wait time to receive data from the sending server. A configuration reload applies a new value; existing work already in flight is not retroactively changed.","A standby terminates its receiver after this period without sender data, then reconnects according to recovery behavior. It is failure detection, not an end-to-end failover deadline, and must tolerate expected network pauses.","Monitor and change wal_receiver_timeout together with primary_conninfo, primary_slot_name, restore_command. 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: wal_receiver_timeout","url":"https://www.postgresql.org/docs/19/runtime-config-replication.html#GUC-WAL-RECEIVER-TIMEOUT"},{"title":"PostgreSQL 19 release notes","url":"https://www.postgresql.org/docs/19/release-19.html"}],"related":["primary_conninfo","primary_slot_name","restore_command","wal_retrieve_retry_interval","hot_standby","wal_receiver_status_interval"],"summary":"wal_receiver_timeout — Sets the maximum wait time to receive data from the sending server. 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.354874+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_receiver_timeout","last_version":"20","max_val":"","min_val":"","name":"wal_receiver_timeout","position":475,"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:fa9ed1e6fc32c0a04416c927aec063fbf1e609a255f7319427d6b3d93300a126","unit":"","vartype":"integer"}},"Definition":{"Collection":"guc","Key":"wal_receiver_timeout","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"wal_receiver_timeout","SourceRevision":"english-manuals:fa9ed1e6fc32c0a04416c927aec063fbf1e609a255f7319427d6b3d93300a126","Facts":{"boot_val":"60000","category":"Replication / Standby Servers","context":"sighup","description":"Terminate replication connections that are inactive for longer than this amount of time. This is useful for the receiving standby server to detect a primary node 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. This parameter can only be set in the postgresql.conf file or on the server command line.","doc":{"anchor":"GUC-WAL-RECEIVER-TIMEOUT","file":"runtime-config-replication.html","lang":"en","sha256":"c78480a202f8579e2655e080060afe4859c9eb26a16318fb9099dabb178fb32d","slug":"18"},"documented":true,"enumvals":null,"extra_desc":"0 disables the timeout.","lang":"en","max_val":"2147483647","metadata_version":"18","min_val":"0","name":"wal_receiver_timeout","short_desc":"Sets the maximum wait time to receive data from the sending server.","source":"pg-settings-source-snapshot","unit":"ms","vartype":"integer"},"ManualEvidence":{"doc":{"anchor":"GUC-WAL-RECEIVER-TIMEOUT","file":"runtime-config-replication.html","lang":"en","sha256":"c78480a202f8579e2655e080060afe4859c9eb26a16318fb9099dabb178fb32d","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"wal_receiver_timeout","SourceDatabase":"center","Version":"18","Locale":"en","Title":"wal_receiver_timeout","Summary":"Terminate replication connections that are inactive for longer than this amount of time. This is useful for the receiving standby server to detect a primary node 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. This parameter can only be set in the postgresql.conf file or on the server command line.","BodyHTML":"\u003cp\u003eTerminate replication connections that are inactive for longer than this amount of time. This is useful for the receiving standby server to detect a primary node 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. This parameter can only be set in the postgresql.conf file or on the server command line.\u003c/p\u003e","SourceRevision":"english-manuals:fa9ed1e6fc32c0a04416c927aec063fbf1e609a255f7319427d6b3d93300a126","ContentHash":"c40d2a856917645b0b80c1b25d9a2c046d2777047f7b96706dfe2a652615f89e","Payload":{"description":"Terminate replication connections that are inactive for longer than this amount of time. This is useful for the receiving standby server to detect a primary node 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. This parameter can only be set in the postgresql.conf file or on the server command line."}},"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}