idle_replication_slot_timeout

Definition PG 18 manual

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.

How it works

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.

Operational considerations

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.

Workload guidance

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.