Horton
Menu

Re: Unexpected behavior when setting "idle_replication_slot_timeout"

David G. Johnston <david.g.johnston@gmail.com>

View thread
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: "smithpb2250@gmail.com" <smithpb2250@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Fujii Masao <masao.fujii@oss.nttdata.com>, Nisha Moond <nisha.moond412@gmail.com>, Gunnar Morling <gunnar.morling@googlemail.com>, "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Date: 2025-07-05T14:38:47Z
Lists: pgsql-bugs 
On Saturday, July 5, 2025, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>
>
> I am sure that there is some information in these sentences, but I cannot
> extract it, even after reading them twice.
>
>
Maybe: “During checkpoint if the interval since
pg_replication_slots.inactive_since and now is larger than this value
pg_replication_slots.conflicting is set to true and
pg_replication_slots.inactive_reason is set to ‘timeout’.  See section
wherever for more information on handling conflicted slots.”

Heck, writing this, “idle” is probably better, a slot can recover from
being idle on its own but usually inactive would imply having to do
something to make it active again.

IMO our documentation for replication has serious flaws but this particular
area is clear enough.  Like any good timeout the slot is killed if it goes
unused “idle” for some length of time.  We can describe that in many ways
but the name, to me, is fully descriptive and consistent with other
timeouts like “idle_in_transaction_timeout”.

David J.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. doc: Clarify meaning of "idle" in idle_replication_slot_timeout.

  2. Change unit of idle_replication_slot_timeout to seconds.