{"Entry":{"collection":"guc","key":"replication_timeout","name":"replication_timeout","aliases":[],"metadata":{"baseline":false,"boot_human":"1 min","boot_val":"60000","category":"Replication / Sending Servers","category_zh":"","changed_in":["9.2"],"changes":[{"documentation_changed":false,"fields":{},"from":"9.0","status":"added","to":"9.1"},{"documentation_changed":true,"fields":{"category":{"from":"Replication / Master Server","to":"Replication / Sending Servers"}},"from":"9.1","status":"changed","to":"9.2"},{"documentation_changed":false,"fields":{},"from":"9.2","status":"removed","to":"9.3"}],"content_hash":"5a02c03e80ac718552aa25c2bebdcf88019e2690d2ea52476809dd4b6415205b","context":"sighup","default_changed_in":[],"default_history":[{"from":"9.1","to":"9.2","value":"1 min"}],"editorial":{"advice":{"olap":"For an upgrade or analytical estate, inventory every generated configuration before cutover. Map the old control to its successor and compare plans, throughput, WAL, or logging behavior rather than assuming the old numeric value is portable.","oltp":"Do not add this retired name to a current OLTP configuration. Translate its intent to the documented successor, test the migration under connection and write concurrency, and remove stale automation that still emits it.","small":"Delete the obsolete override after recording why it existed. On a small node, prefer the successor's default until measurements justify a new value; an unknown startup parameter can otherwise stop the server."},"mechanism":["PostgreSQL describes replication_timeout as follows: “Sets the maximum time to wait for WAL replication.” A configuration reload applies the value to the server without a full restart. The atlas measures it in PG9.1–9.2; boot_val is the compiled or initialized baseline, not proof of a running cluster's effective setting.","This early streaming-replication timeout let a sender terminate an inactive connection. PostgreSQL 9.3 replaced the name with wal_sender_timeout; receiver-side failure detection is separately controlled by wal_receiver_timeout, so migration must preserve which side of the connection owns the timer.","Read it together with wal_sender_timeout, wal_receiver_timeout, wal_receiver_status_interval, max_wal_senders. Check SHOW and pg_settings on the target server, verify the source and pending_restart fields, and compare workload, logs, and resource metrics before and after any change."],"pitfalls":["Treating the measured boot_val for replication_timeout as proof of the effective value on an initialized or managed cluster.","Applying a change as though it were immediate while pg_settings reports sighup context.","Changing this setting in isolation without checking the linked limits, observability, and rollback path.","Copying the removed name into a modern postgresql.conf instead of migrating to its documented successor."],"references":[],"related":["wal_sender_timeout","wal_receiver_timeout","wal_receiver_status_interval","max_wal_senders"],"summary":"replication_timeout — Sets the maximum time to wait for WAL replication. Observed in PG9.1–9.2; its last measured boot default is 1 min in PG9.2, with sighup context. It was removed in PG9.3."},"enumvals":[],"first_version":"9.1","group":"Replication","group_slug":"replication","imported_at":"2026-09-27T17:57:31.90583+08:00","intro_commit":{"authored_at":"2011-03-30T10:10:32+03:00","discussion":[],"hash":"754baa21f723255272c24dc5f9ab456858e361e3","subject":"Automatically terminate replication connections that are idle for more than replication_timeout (a new GUC) milliseconds. The TCP timeout is often too long, you want the master to notice a dead connection much sooner. People complained about that in 9.0 too, but with synchronous replication it's even more important to notice dead connections promptly.","url":"https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=754baa21f723255272c24dc5f9ab456858e361e3"},"key":"replication_timeout","last_version":"9.2","max_val":"2147483647","min_val":"0","name":"replication_timeout","position":339,"present_in":["9.1","9.2"],"short_desc":"Terminate replication connections that are inactive longer than the specified number of milliseconds.","short_desc_zh":"","source_rev":"english-manuals:b92cb2390135a093fc0ccf4978ab3b7a279ff79634fc49b760155cd00ea8f038","unit":"ms","vartype":"integer"}},"Definition":{"Collection":"guc","Key":"replication_timeout","SourceDatabase":"center","Version":"9.2","SourceTable":"guc","SourceKey":"replication_timeout","SourceRevision":"english-manuals:b92cb2390135a093fc0ccf4978ab3b7a279ff79634fc49b760155cd00ea8f038","Facts":{"boot_val":"60000","category":"Replication / Sending Servers","context":"sighup","description":"Terminate replication connections that are inactive longer than the specified number of milliseconds. This is useful for the sending server to detect a standby crash or network outage. 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. The default value is 60 seconds. To prevent connections from being terminated prematurely, wal_receiver_status_interval must be enabled on the standby, and its value must be less than the value of replication_timeout.","doc":{"anchor":"GUC-REPLICATION-TIMEOUT","file":"runtime-config-replication.html","lang":"en","sha256":"609be569b28115a30ffe223a3c876c9c8d26556b14386df7ff348e385d007a95","slug":"9.2"},"documented":true,"enumvals":null,"extra_desc":null,"lang":"en","max_val":"2147483647","metadata_version":"9.2","min_val":"0","name":"replication_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-REPLICATION-TIMEOUT","file":"runtime-config-replication.html","lang":"en","sha256":"609be569b28115a30ffe223a3c876c9c8d26556b14386df7ff348e385d007a95","slug":"9.2"}},"MeasuredEvidence":{"metadata_version":"9.2"}},"Text":{"Collection":"guc","Key":"replication_timeout","SourceDatabase":"pgweb","Version":"9.2","Locale":"zh-Hans","Title":"replication_timeout","Summary":"","BodyHTML":"\u003cp\u003e终止不活动时间超过指定毫秒数的复制连接。这有助于主库检测备库崩溃或网络中断。值为零将禁用超时机制。这个参数只能在\u003ccode\u003epostgresql.conf\u003c/code\u003e文件中或在服务器命令行上设置。默认值为 60 秒。\u003c/p\u003e\u003cp\u003e为防止连接被过早终止，必须在备库上启用\u003ca href=\"/docs/9.2/runtime-config-replication.html#GUC-WAL-RECEIVER-STATUS-INTERVAL\" rel=\"nofollow\"\u003ewal_receiver_status_interval\u003c/a\u003e，并且它的值必须小于\u003ccode\u003ereplication_timeout\u003c/code\u003e的值。\u003c/p\u003e","SourceRevision":"2026-09-11@29c86d9","ContentHash":"de809ca943e7f876d4c807e4d37ab8d2ff43e5c422ff6124b683c1218cee88af","Payload":{"carried_from":"","carry_reason":"","doc_html":"\u003cp\u003e终止不活动时间超过指定毫秒数的复制连接。这有助于主库检测备库崩溃或网络中断。值为零将禁用超时机制。这个参数只能在\u003ccode class=\"filename\"\u003epostgresql.conf\u003c/code\u003e文件中或在服务器命令行上设置。默认值为 60 秒。\u003c/p\u003e\u003cp\u003e为防止连接被过早终止，必须在备库上启用\u003ca href=\"/docs/9.2/runtime-config-replication.html#GUC-WAL-RECEIVER-STATUS-INTERVAL\"\u003ewal_receiver_status_interval\u003c/a\u003e，并且它的值必须小于\u003ccode class=\"varname\"\u003ereplication_timeout\u003c/code\u003e的值。\u003c/p\u003e","doc_same_as":""}},"RequestedLocale":"zh-Hans","Fallback":false,"Versions":["9.1","9.2"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}