{"Entry":{"collection":"guc","key":"idle_replication_slot_timeout","name":"idle_replication_slot_timeout","aliases":[],"metadata":{"baseline":false,"boot_human":"Not specified","boot_val":null,"category":"Replication / Sending Servers","category_zh":"","changed_in":["19"],"changes":[{"documentation_changed":false,"fields":{},"from":"17","status":"added","to":"18"},{"documentation_changed":false,"fields":{"extra_desc":{"from":null,"to":"0 disables the timeout."}},"from":"18","status":"changed","to":"19"}],"content_hash":"bdf54c22dd7d02074c46753c6af0737f4edc9fc71aa70c9976540ce780dc63af","context":"","default_changed_in":[],"default_history":[{"from":"18","to":"19","value":"0 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 idle_replication_slot_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 duration a replication slot can remain idle before it is invalidated. A configuration reload applies a new value; existing work already in flight is not retroactively changed.","PostgreSQL 18 measures inactivity from pg_replication_slots.inactive_since and invalidates eligible slots at a checkpoint after the timeout. Zero disables the policy; slots that reserve no WAL and synchronized standby slots are outside this mechanism.","Monitor and change idle_replication_slot_timeout together with max_replication_slots, max_slot_wal_keep_size, primary_slot_name. 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":["Expecting invalidation exactly when the duration expires rather than at a later checkpoint.","Assuming synchronized standby slots are eligible.","Allowing an automatic invalidation without a subscriber rebootstrap runbook.","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: idle_replication_slot_timeout","url":"https://www.postgresql.org/docs/19/runtime-config-replication.html#GUC-IDLE-REPLICATION-SLOT-TIMEOUT"},{"title":"PostgreSQL 19 release notes","url":"https://www.postgresql.org/docs/19/release-19.html"}],"related":["max_replication_slots","max_slot_wal_keep_size","primary_slot_name","wal_keep_size","checkpoint_timeout","max_wal_senders"],"summary":"idle_replication_slot_timeout — Sets the duration a replication slot can remain idle before it is invalidated. Observed in PG18–19 Beta 4; its last measured boot default is 0 s in PG19 Beta 4, with sighup context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA."},"enumvals":[],"first_version":"18","group":"Replication","group_slug":"replication","imported_at":"2026-09-27T17:57:31.380455+08:00","intro_commit":{"authored_at":"2025-02-19T09:29:50+05:30","discussion":["https://postgr.es/m/CALj2ACW4aUe-_uFQOjdWCEN-xXoLGhmvRFnL8SNw_TZ5nJe+aw@mail.gmail.com","https://postgr.es/m/OS0PR01MB5716C131A7D80DAE8CB9E88794FC2@OS0PR01MB5716.jpnprd01.prod.outlook.com"],"hash":"ac0e33136abc4668c9b08e1ba7db69afe1e0e2c3","subject":"Invalidate inactive replication slots.","url":"https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=ac0e33136abc4668c9b08e1ba7db69afe1e0e2c3"},"key":"idle_replication_slot_timeout","last_version":"20","max_val":"","min_val":"","name":"idle_replication_slot_timeout","position":174,"present_in":["18","19","20"],"short_desc":"Invalidate replication slots that have remained inactive (not used by a replication connection) for longer than this duration.","short_desc_zh":"","source_rev":"english-manuals:09d38ea7b54e2d5006ed90950917d10632305b773e3635bac3dcaad9ad3ae17c","unit":"","vartype":"integer"}},"Definition":{"Collection":"guc","Key":"idle_replication_slot_timeout","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"idle_replication_slot_timeout","SourceRevision":"english-manuals:09d38ea7b54e2d5006ed90950917d10632305b773e3635bac3dcaad9ad3ae17c","Facts":{"boot_val":"0","category":"Replication / Sending Servers","context":"sighup","description":"Invalidate replication slots that have remained inactive (not used by a replication connection) for longer than this duration. If this value is specified without units, it is taken as seconds. A value of zero (the default) disables the idle timeout invalidation mechanism. This parameter can only be set in the postgresql.conf file or on the server command line. Slot invalidation due to idle timeout occurs during checkpoint. Because checkpoints happen at checkpoint_timeout intervals, there can be some lag between when the idle_replication_slot_timeout was exceeded and when the slot invalidation is triggered at the next checkpoint. To avoid such lags, users can force a checkpoint to promptly invalidate inactive slots. The duration of slot inactivity is calculated using the slot's pg_replication_slots.inactive_since value. Note that the idle timeout invalidation mechanism is not applicable for slots that do not reserve WAL or for slots on the standby server that are being synced from the primary server (i.e., standby slots having pg_replication_slots.synced value true). Synced slots are always considered to be inactive because they don't perform logical decoding to produce changes.","doc":{"anchor":"GUC-IDLE-REPLICATION-SLOT-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":"idle_replication_slot_timeout","short_desc":"Sets the duration a replication slot can remain idle before it is invalidated.","source":"pg-settings-source-snapshot","unit":"s","vartype":"integer"},"ManualEvidence":{"doc":{"anchor":"GUC-IDLE-REPLICATION-SLOT-TIMEOUT","file":"runtime-config-replication.html","lang":"en","sha256":"c78480a202f8579e2655e080060afe4859c9eb26a16318fb9099dabb178fb32d","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"idle_replication_slot_timeout","SourceDatabase":"pgweb","Version":"18","Locale":"zh-Hans","Title":"idle_replication_slot_timeout","Summary":"","BodyHTML":"\u003cp\u003e使保持空闲状态（未被\u003ca href=\"/docs/18/protocol-replication.html\" rel=\"nofollow\"\u003e复制连接\u003c/a\u003e使用）超过此持续时间的复制槽失效。如果指定值时没有单位，则以秒为单位。零值（默认值）将禁用空闲超时失效机制。该参数只能在\u003ccode\u003epostgresql.conf\u003c/code\u003e文件中或服务器命令行上设置。\u003c/p\u003e\u003cp\u003e由于空闲超时导致的槽失效会在检查点期间发生。由于检查点每隔 \u003ccode\u003echeckpoint_timeout\u003c/code\u003e触发一次，因此从 \u003ccode\u003eidle_replication_slot_timeout\u003c/code\u003e超时到下一个检查点使槽失效之间可能会有一些延迟。若要避免这种延迟，用户可以强制执行检查点，以便及时使不活动的槽失效。槽的不活动时间根据其 \u003ca href=\"/docs/18/view-pg-replication-slots.html\" rel=\"nofollow\"\u003epg_replication_slots\u003c/a\u003e.\u003ccode\u003einactive_since\u003c/code\u003e值计算。\u003c/p\u003e\u003cp\u003e请注意，空闲超时失效机制不适用于不保留 WAL 的槽，也不适用于正在从主库同步的备库上的槽（即\u003ca href=\"/docs/18/view-pg-replication-slots.html\" rel=\"nofollow\"\u003epg_replication_slots\u003c/a\u003e.\u003ccode\u003esynced\u003c/code\u003e 值为\u003ccode\u003etrue\u003c/code\u003e的备库槽）。已同步的槽总是被视为空闲，因为它们不会执行逻辑解码来生成变更。\u003c/p\u003e","SourceRevision":"2026-09-11@29c86d9","ContentHash":"1553047048f81e417de5e1cfdae25b7e8c12547054e2b4cf1b368f3dd043cc27","Payload":{"carried_from":"","carry_reason":"","doc_html":"\u003cp\u003e使保持空闲状态（未被\u003ca href=\"/docs/18/protocol-replication.html\" title=\"54.4. 流复制协议\"\u003e复制连接\u003c/a\u003e使用）超过此持续时间的复制槽失效。如果指定值时没有单位，则以秒为单位。零值（默认值）将禁用空闲超时失效机制。该参数只能在\u003ccode class=\"filename\"\u003epostgresql.conf\u003c/code\u003e文件中或服务器命令行上设置。\u003c/p\u003e\u003cp\u003e由于空闲超时导致的槽失效会在检查点期间发生。由于检查点每隔 \u003ccode class=\"varname\"\u003echeckpoint_timeout\u003c/code\u003e触发一次，因此从 \u003ccode class=\"varname\"\u003eidle_replication_slot_timeout\u003c/code\u003e超时到下一个检查点使槽失效之间可能会有一些延迟。若要避免这种延迟，用户可以强制执行检查点，以便及时使不活动的槽失效。槽的不活动时间根据其 \u003ca href=\"/docs/18/view-pg-replication-slots.html\" title=\"53.20. pg_replication_slots\"\u003epg_replication_slots\u003c/a\u003e.\u003ccode class=\"structfield\"\u003einactive_since\u003c/code\u003e值计算。\u003c/p\u003e\u003cp\u003e请注意，空闲超时失效机制不适用于不保留 WAL 的槽，也不适用于正在从主库同步的备库上的槽（即\u003ca href=\"/docs/18/view-pg-replication-slots.html\" title=\"53.20. pg_replication_slots\"\u003epg_replication_slots\u003c/a\u003e.\u003ccode class=\"structfield\"\u003esynced\u003c/code\u003e 值为\u003ccode class=\"literal\"\u003etrue\u003c/code\u003e的备库槽）。已同步的槽总是被视为空闲，因为它们不会执行逻辑解码来生成变更。\u003c/p\u003e","doc_same_as":""}},"RequestedLocale":"zh-Hans","Fallback":false,"Versions":["18","19","20"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}