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(dot)morling(at)googlemail(dot)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 timeout had 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 rounded down 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