Re: Unexpected behavior when setting "idle_replication_slot_timeout"
Gunnar Morling <gunnar.morling@googlemail.com>
From: Gunnar Morling <gunnar.morling@googlemail.com>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>,
Nisha Moond <nisha.moond412@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2025-07-04T18:59:00Z
Lists: pgsql-bugs
Hey all, Thanks for all the replies! Indeed I also wouldn't expect anyone to set this timeout to 30s for purposes other than testing or exploration. But then again, if the option can be set with second precision, is there any reason to not honor this? To me, it boils down to the principle of least surprise for users, in particular when it comes to a setting like "30s" being interpreted as disabling the feature. > What exactly does it mean for a replication slot to idle? I'd like to echo this; I also was/am confused by the term "idle" here; it isn't fully clear to me what it means for a slot to be idle, and in particular whether it is different from a slot being inactive. pg_replication_slots uses the "active"/"inactive" terminology, and it seems that this is what idleness is about, as per the docs of the setting [1]: > [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. If so, "inactive_replication_slot_timeout" might be a more consistent name for that option? Best, --Gunnar [1] https://www.postgresql.org/docs/18/runtime-config-replication.html#GUC-IDLE-REPLICATION-SLOT-TIMEOUT On Fri, 4 Jul 2025 at 18:24, Fujii Masao <masao.fujii@oss.nttdata.com> wrote: > > > On 2025/07/05 1:07, Laurenz Albe wrote: > > On Sat, 2025-07-05 at 00:22 +0900, Fujii Masao wrote: > >> On 2025/07/04 23:12, Fujii Masao wrote: > >>> But I wonder why the current unit of this GUC is minutes > (GUC_UNIT_MIN). > >>> Since at least two users (including myself) tried to set it to a value > >>> less than 1 minute, it might worth considering changing the unit to > seconds > >>> (GUC_UNIT_S). Also which would reduces the chance of the reported > trouble. > >> > >> Attached patch changes unit of idle_replication_slot_timeout to seconds. > > > > -1 > > > > I think that the reason that several users tried to set it it less than > a minute > > is that they were trying to test the feature and didn't want to wait > long. > > I cannot imagine that anybody will want to abandon a standby server just > > because it is idle for more than 30 seconds. > > Maybe. But changing the unit to seconds doesn't make things worse, does it? > It still allows users to set values greater than 1 minute, and also less > than > 1 minute for debugging or testing purposes, if needed. > > Or are you suggesting we should disallow values below 1 minute? > > Regards, > > -- > Fujii Masao > NTT DATA Japan Corporation > >
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
doc: Clarify meaning of "idle" in idle_replication_slot_timeout.
- afb64a56d9c1 18.0 landed
- 110e6dcaa659 19 (unreleased) landed
-
Change unit of idle_replication_slot_timeout to seconds.
- 37c76aeb9ae3 18.0 landed
- 05dedf43d380 19 (unreleased) landed