{"Entry":{"collection":"guc","key":"wal_retrieve_retry_interval","name":"wal_retrieve_retry_interval","aliases":[],"metadata":{"baseline":false,"boot_human":"Not specified","boot_val":null,"category":"Replication / Standby Servers","category_zh":"","changed_in":[],"changes":[{"documentation_changed":false,"fields":{},"from":"9.4","status":"added","to":"9.5"},{"documentation_changed":true,"fields":{},"from":"9.6","status":"changed","to":"10"},{"documentation_changed":true,"fields":{},"from":"11","status":"changed","to":"12"},{"documentation_changed":true,"fields":{},"from":"14","status":"changed","to":"15"},{"documentation_changed":true,"fields":{},"from":"15","status":"changed","to":"16"},{"documentation_changed":true,"fields":{},"from":"17","status":"changed","to":"18"},{"documentation_changed":true,"fields":{},"from":"18","status":"changed","to":"19"}],"content_hash":"20e2f1d62aaed482219676b0638c5e5de9090a2d84cb365561be81e9c067b7ad","context":"","default_changed_in":[],"default_history":[{"from":"9.5","to":"19","value":"5 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 wal_retrieve_retry_interval 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 time to wait before retrying to retrieve WAL after a failed attempt. A configuration reload applies a new value; existing work already in flight is not retroactively changed.","After archive, local pg_wal, and streaming retrieval fail, recovery waits this long before another attempt. Small values reduce recovery/standby reaction time but can hammer a missing archive or noisy network with retries.","Monitor and change wal_retrieve_retry_interval 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_retrieve_retry_interval","url":"https://www.postgresql.org/docs/19/runtime-config-replication.html#GUC-WAL-RETRIEVE-RETRY-INTERVAL"},{"title":"PostgreSQL 19 release notes","url":"https://www.postgresql.org/docs/19/release-19.html"}],"related":["primary_conninfo","primary_slot_name","restore_command","wal_receiver_timeout","hot_standby","hot_standby_feedback"],"summary":"wal_retrieve_retry_interval — Sets the time to wait before retrying to retrieve WAL after a failed attempt. Observed in PG9.5–19 Beta 4; its last measured boot default is 5 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.5","group":"Replication","group_slug":"replication","imported_at":"2026-09-27T17:57:32.36+08:00","intro_commit":{"authored_at":"2015-02-23T20:55:17+09:00","discussion":[],"hash":"5d2b45e3f78a85639f30431181c06d4c3221c5a1","subject":"Add GUC to control the time to wait before retrieving WAL after failed attempt.","url":"https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5d2b45e3f78a85639f30431181c06d4c3221c5a1"},"key":"wal_retrieve_retry_interval","last_version":"20","max_val":"","min_val":"","name":"wal_retrieve_retry_interval","position":477,"present_in":["9.5","9.6","10","11","12","13","14","15","16","17","18","19","20"],"short_desc":"Specifies how long the standby server should wait when WAL data is not available from any sources (streaming replication, local pg_wal or WAL archive) before trying again to retrieve WAL data.","short_desc_zh":"","source_rev":"english-manuals:7e1027458894c3d8c6c81b85dd0f8cd92411c14e1f07dbb55e37f0c91833c29a","unit":"","vartype":"integer"}},"Definition":{"Collection":"guc","Key":"wal_retrieve_retry_interval","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"wal_retrieve_retry_interval","SourceRevision":"english-manuals:7e1027458894c3d8c6c81b85dd0f8cd92411c14e1f07dbb55e37f0c91833c29a","Facts":{"boot_val":"5000","category":"Replication / Standby Servers","context":"sighup","description":"Specifies how long the standby server should wait when WAL data is not available from any sources (streaming replication, local pg_wal or WAL archive) before trying again to retrieve WAL data. If this value is specified without units, it is taken as milliseconds. The default value is 5 seconds. This parameter can only be set in the postgresql.conf file or on the server command line. This parameter is useful in configurations where a node in recovery needs to control the amount of time to wait for new WAL data to be available. For example, in archive recovery, it is possible to make the recovery more responsive in the detection of a new WAL file by reducing the value of this parameter. On a system with low WAL activity, increasing it reduces the amount of requests necessary to access WAL archives, something useful for example in cloud environments where the number of times an infrastructure is accessed is taken into account. In logical replication, this parameter also limits how often a failing replication apply worker or table synchronization worker will be respawned.","doc":{"anchor":"GUC-WAL-RETRIEVE-RETRY-INTERVAL","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":"1","name":"wal_retrieve_retry_interval","short_desc":"Sets the time to wait before retrying to retrieve WAL after a failed attempt.","source":"pg-settings-source-snapshot","unit":"ms","vartype":"integer"},"ManualEvidence":{"doc":{"anchor":"GUC-WAL-RETRIEVE-RETRY-INTERVAL","file":"runtime-config-replication.html","lang":"en","sha256":"c78480a202f8579e2655e080060afe4859c9eb26a16318fb9099dabb178fb32d","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"wal_retrieve_retry_interval","SourceDatabase":"pgweb","Version":"18","Locale":"zh-Hans","Title":"wal_retrieve_retry_interval","Summary":"","BodyHTML":"\u003cp\u003e指定当从任何来源（流复制、本地\u003ccode\u003epg_wal\u003c/code\u003e或者 WAL 归档）都得不到 WAL 数据时，备库应该等待多久才去重新尝试获取 WAL 数据。如果指定值时没有单位，则以毫秒为单位。默认值是 5 秒。这个参数只能在\u003ccode\u003epostgresql.conf\u003c/code\u003e文件或者服务器命令行中设置。\u003c/p\u003e\u003cp\u003e这个参数在恢复节点需要控制等待新 WAL 数据可用时长的配置中很有用。例如，在归档恢复中，降低该参数的值可以让系统在检测到新 WAL 文件时更快作出响应；在 WAL 活动较低的系统上，增大该值则可以减少访问 WAL 归档所需的请求次数，这在对基础设施访问次数进行计量的云环境中尤其有用。\u003c/p\u003e\u003cp\u003e在逻辑复制中，该参数还限制失败的复制应用工作进程或表同步工作进程被重新启动的频率。\u003c/p\u003e","SourceRevision":"2026-09-11@29c86d9","ContentHash":"96f24a6887f3b29a6f736c955efd678e9bf35cca4d699aa200c133ad1dc072c9","Payload":{"carried_from":"","carry_reason":"","doc_html":"\u003cp\u003e指定当从任何来源（流复制、本地\u003ccode class=\"filename\"\u003epg_wal\u003c/code\u003e或者 WAL 归档）都得不到 WAL 数据时，备库应该等待多久才去重新尝试获取 WAL 数据。如果指定值时没有单位，则以毫秒为单位。默认值是 5 秒。这个参数只能在\u003ccode class=\"filename\"\u003epostgresql.conf\u003c/code\u003e文件或者服务器命令行中设置。\u003c/p\u003e\u003cp\u003e这个参数在恢复节点需要控制等待新 WAL 数据可用时长的配置中很有用。例如，在归档恢复中，降低该参数的值可以让系统在检测到新 WAL 文件时更快作出响应；在 WAL 活动较低的系统上，增大该值则可以减少访问 WAL 归档所需的请求次数，这在对基础设施访问次数进行计量的云环境中尤其有用。\u003c/p\u003e\u003cp\u003e在逻辑复制中，该参数还限制失败的复制应用工作进程或表同步工作进程被重新启动的频率。\u003c/p\u003e","doc_same_as":""}},"RequestedLocale":"zh-Hans","Fallback":false,"Versions":["10","11","12","13","14","15","16","17","18","19","20","9.5","9.6"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}