Invalidate replication slots that have remained inactive (not used by a replication connection) for longer than this duration.
At a glance
| Property | Value |
|---|---|
| Parameter | idle_replication_slot_timeout |
| Category | Replication |
| Default | (see documentation) |
| Value type | integer |
| Change scope | Reload (postgresql.conf, SIGHUP) |
| Available in | PostgreSQL 18, 19 (added in 18) |
What it does
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.
(Description quoted from the official PostgreSQL documentation.)
How to apply a change
Set it in postgresql.conf (or with ALTER SYSTEM) and reload with SELECT pg_reload_conf(); or pg_ctl reload — no restart needed.
Inspect the current value and source with SHOW idle_replication_slot_timeout; or SELECT name, setting, unit, context, source FROM pg_settings WHERE name = 'idle_replication_slot_timeout';.
Tuning guidance
This parameter is rarely a performance lever. Leave it at the default unless you have a specific, documented reason to change it, change it on one session or one role/database first, and confirm the effect with pg_settings and your own measurements before rolling it out cluster-wide.