{"Entry":{"collection":"guc","key":"synchronized_standby_slots","name":"synchronized_standby_slots","aliases":[],"metadata":{"baseline":false,"boot_human":"Not specified","boot_val":null,"category":"Replication / Primary Server","category_zh":"","changed_in":[],"changes":[{"documentation_changed":false,"fields":{},"from":"16","status":"added","to":"17"}],"content_hash":"5596b9dbbfab6451832ffe634bbec229eaee78a58be82d4a15945a9bf6b08919","context":"","default_changed_in":[],"default_history":[{"from":"17","to":"19","value":"Empty string"}],"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 synchronized_standby_slots 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":["Lists streaming replication standby server replication slot names that logical WAL sender processes will wait for. A configuration reload applies a new value; existing work already in flight is not retroactively changed.","Logical senders on the primary wait until every listed physical standby slot has confirmed the relevant WAL before decoding sends changes. This protects failover-slot continuity, but a missing, invalid, or stalled listed slot can stop logical replication and slot-management functions.","Monitor and change synchronized_standby_slots together with sync_replication_slots, primary_slot_name, max_replication_slots. 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":["Listing a missing or invalid slot and blocking logical senders.","Confusing physical slot names with standby application_name values.","Failing to enable sync_replication_slots on the corresponding standbys.","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."],"references":[{"title":"PostgreSQL 19 Beta 4: synchronized_standby_slots","url":"https://www.postgresql.org/docs/19/runtime-config-replication.html#GUC-SYNCHRONIZED-STANDBY-SLOTS"},{"title":"PostgreSQL 19 release notes","url":"https://www.postgresql.org/docs/19/release-19.html"}],"related":["sync_replication_slots","primary_slot_name","max_replication_slots","max_slot_wal_keep_size","synchronous_standby_names","vacuum_defer_cleanup_age"],"summary":"synchronized_standby_slots lists streaming replication standby server replication slot names that logical WAL sender processes will wait for. It is a sighup setting present in PG17–18; the latest recorded boot default is empty."},"enumvals":[],"first_version":"17","group":"Replication","group_slug":"replication","imported_at":"2026-09-27T17:57:32.093853+08:00","intro_commit":{"authored_at":"2024-07-01T11:02:04+05:30","discussion":["https://postgr.es/m/ZnWeUgdHong93fQN@momjian.us"],"hash":"0f934b0739ad28e8e20d8ad22ca80538544ce28a","subject":"Rename standby_slot_names to synchronized_standby_slots.","url":"https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=0f934b0739ad28e8e20d8ad22ca80538544ce28a"},"key":"synchronized_standby_slots","last_version":"20","max_val":"","min_val":"","name":"synchronized_standby_slots","position":398,"present_in":["17","18","19","20"],"short_desc":"A comma-separated list of streaming replication standby server slot names that logical WAL sender processes will wait for.","short_desc_zh":"","source_rev":"english-manuals:43cc772b85efab1d671752584284441744c857d3100dffead45b0bed66860c5c","unit":"","vartype":"string"}},"Definition":{"Collection":"guc","Key":"synchronized_standby_slots","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"synchronized_standby_slots","SourceRevision":"english-manuals:43cc772b85efab1d671752584284441744c857d3100dffead45b0bed66860c5c","Facts":{"boot_val":"","category":"Replication / Primary Server","context":"sighup","description":"A comma-separated list of streaming replication standby server slot names that logical WAL sender processes will wait for. Logical WAL sender processes will send decoded changes to plugins only after the specified replication slots confirm receiving WAL. This guarantees that logical replication failover slots do not consume changes until those changes are received and flushed to corresponding physical standbys. If a logical replication connection is meant to switch to a physical standby after the standby is promoted, the physical replication slot for the standby should be listed here. Note that logical replication will not proceed if the slots specified in the synchronized_standby_slots do not exist or are invalidated. Additionally, the replication management functions pg_replication_slot_advance, pg_logical_slot_get_changes, and pg_logical_slot_peek_changes, when used with logical failover slots, will block until all physical slots specified in synchronized_standby_slots have confirmed WAL receipt. The standbys corresponding to the physical replication slots in synchronized_standby_slots must configure sync_replication_slots = true so they can receive logical failover slot changes from the primary.","doc":{"anchor":"GUC-SYNCHRONIZED-STANDBY-SLOTS","file":"runtime-config-replication.html","lang":"en","sha256":"c78480a202f8579e2655e080060afe4859c9eb26a16318fb9099dabb178fb32d","slug":"18"},"documented":true,"enumvals":null,"extra_desc":"Logical WAL sender processes will send decoded changes to output plugins only after the specified replication slots have confirmed receiving WAL.","lang":"en","max_val":null,"metadata_version":"18","min_val":null,"name":"synchronized_standby_slots","short_desc":"Lists streaming replication standby server replication slot names that logical WAL sender processes will wait for.","source":"pg-settings-source-snapshot","unit":null,"vartype":"string"},"ManualEvidence":{"doc":{"anchor":"GUC-SYNCHRONIZED-STANDBY-SLOTS","file":"runtime-config-replication.html","lang":"en","sha256":"c78480a202f8579e2655e080060afe4859c9eb26a16318fb9099dabb178fb32d","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"synchronized_standby_slots","SourceDatabase":"pgweb","Version":"18","Locale":"zh-Hans","Title":"synchronized_standby_slots","Summary":"","BodyHTML":"\u003cp\u003e逻辑 WAL 发送进程将等待的流复制备库槽名称的逗号分隔列表。逻辑 WAL 发送进程仅在指定复制槽确认接收 WAL 后，才会把解码后的更改发送给插件。这可以确保逻辑复制故障切换槽在相应物理备库接收这些更改并将其刷盘之前，不会消耗这些更改。如果逻辑复制连接需要在物理备库被提升后切换到该备库，则应在这里列出该备库的物理复制槽。请注意，如果\u003ccode\u003esynchronized_standby_slots\u003c/code\u003e中指定的槽不存在或无效，逻辑复制将不会继续。此外，使用逻辑故障切换槽的复制管理函数 \u003ca href=\"/docs/18/functions-admin.html#PG-REPLICATION-SLOT-ADVANCE\" rel=\"nofollow\"\u003e\u003ccode\u003epg_replication_slot_advance\u003c/code\u003e\u003c/a\u003e、\u003ca href=\"/docs/18/functions-admin.html#PG-LOGICAL-SLOT-GET-CHANGES\" rel=\"nofollow\"\u003e\u003ccode\u003epg_logical_slot_get_changes\u003c/code\u003e\u003c/a\u003e和 \u003ca href=\"/docs/18/functions-admin.html#PG-LOGICAL-SLOT-PEEK-CHANGES\" rel=\"nofollow\"\u003e\u003ccode\u003epg_logical_slot_peek_changes\u003c/code\u003e\u003c/a\u003e 将阻塞，直到\u003ccode\u003esynchronized_standby_slots\u003c/code\u003e中列出的所有物理槽都确认接收到了 WAL。\u003c/p\u003e\u003cp\u003e与\u003ccode\u003esynchronized_standby_slots\u003c/code\u003e中物理复制槽对应的备库必须配置 \u003ccode\u003esync_replication_slots = true\u003c/code\u003e，这样它们才能从主库接收逻辑故障切换槽的更改。\u003c/p\u003e","SourceRevision":"2026-09-11@29c86d9","ContentHash":"e8d681826907a6c08009473482a8427bb4659ab030591c7c137112082e7ef057","Payload":{"carried_from":"","carry_reason":"","doc_html":"\u003cp\u003e逻辑 WAL 发送进程将等待的流复制备库槽名称的逗号分隔列表。逻辑 WAL 发送进程仅在指定复制槽确认接收 WAL 后，才会把解码后的更改发送给插件。这可以确保逻辑复制故障切换槽在相应物理备库接收这些更改并将其刷盘之前，不会消耗这些更改。如果逻辑复制连接需要在物理备库被提升后切换到该备库，则应在这里列出该备库的物理复制槽。请注意，如果\u003ccode class=\"varname\"\u003esynchronized_standby_slots\u003c/code\u003e中指定的槽不存在或无效，逻辑复制将不会继续。此外，使用逻辑故障切换槽的复制管理函数 \u003ca href=\"/docs/18/functions-admin.html#PG-REPLICATION-SLOT-ADVANCE\"\u003e\u003ccode class=\"function\"\u003epg_replication_slot_advance\u003c/code\u003e\u003c/a\u003e、\u003ca href=\"/docs/18/functions-admin.html#PG-LOGICAL-SLOT-GET-CHANGES\"\u003e\u003ccode class=\"function\"\u003epg_logical_slot_get_changes\u003c/code\u003e\u003c/a\u003e和 \u003ca href=\"/docs/18/functions-admin.html#PG-LOGICAL-SLOT-PEEK-CHANGES\"\u003e\u003ccode class=\"function\"\u003epg_logical_slot_peek_changes\u003c/code\u003e\u003c/a\u003e 将阻塞，直到\u003ccode class=\"varname\"\u003esynchronized_standby_slots\u003c/code\u003e中列出的所有物理槽都确认接收到了 WAL。\u003c/p\u003e\u003cp\u003e与\u003ccode class=\"varname\"\u003esynchronized_standby_slots\u003c/code\u003e中物理复制槽对应的备库必须配置 \u003ccode class=\"literal\"\u003esync_replication_slots = true\u003c/code\u003e，这样它们才能从主库接收逻辑故障切换槽的更改。\u003c/p\u003e","doc_same_as":""}},"RequestedLocale":"zh-Hans","Fallback":false,"Versions":["17","18","19","20"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}