Re: Unexpected behavior when setting "idle_replication_slot_timeout"

On 2025/07/04 21:14, Nisha Moond wrote:
> On Fri, Jul 4, 2025 at 4:35 PM Gunnar Morling
> <gunnar.morling@googlemail.com> wrote:
>>
>> Hi all,
>>
>> I am exploring the new setting "idle_replication_slot_timeout" in Postgres 18; for testing purposes, I set the value
to"30s", which, unexpectedly to me, didn't cause an idle slot to be invalidated when I triggered a checkpoint after the
timeouthad been reached.
 
>>
>> The docs of the option state that the value is rounded up or down to the nearest full minute, so I reckon "30s" gets
roundeddown to 0, thus effectively disabling the feature.
 

When I first tried using idle_replication_slot_timeout, I also encountered this issue.


> It might be less surprising to users if values between "1s" and "59s" get actually always rounded up to one minute?
Arguably,that'd seem the more intuitive behavior to me. Alternatively, logging a warning might be considered for values
between"1s" and "30s"? Curious what folks here think.
 
>>
> 
> Thanks for bringing this up!
> 
> Yes, this is expected behavior, idle_replication_slot_timeout accepts
> values in minutes, so a setting like "30s" is rounded down to 0,
> effectively disabling the timeout, while values >= "31s" are rounded
> up to 1.
> 
> This behavior isn’t specific to this GUC as Postgres generally rounds
> values below a parameter’s minimum unit without a warning. For
> example, wal_summary_keep_time and log_rotation_age behave the same
> way.

Right.

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.

Regards,

-- 
Fujii Masao
NTT DATA Japan Corporation