Re: Unexpected behavior when setting "idle_replication_slot_timeout"

On Sat, Jul 5, 2025 at 9:43 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I wrote:
> > I'm kind of down on changing the unit, because it will *silently*
> > break configuration files where the value was set without a unit.
>
> Oh, wait a second.  I just noticed that this variable is new in v18.
> So there won't be a compatibility issue as long as we change it in
> v18 too.  So changing it to a base of seconds seems sufficient,
> and more in line with existing practice:
>
> regression=# select name,unit from pg_settings where name like '%timeout';
>                 name                 | unit
> -------------------------------------+------
>  archive_timeout                     | s
>  authentication_timeout              | s
>  checkpoint_timeout                  | s
>  deadlock_timeout                    | ms
>  idle_in_transaction_session_timeout | ms
>  idle_replication_slot_timeout       | min
>  idle_session_timeout                | ms
>  lock_timeout                        | ms
>  statement_timeout                   | ms
>  tcp_user_timeout                    | ms
>  transaction_timeout                 | ms
>  wal_receiver_timeout                | ms
>  wal_sender_timeout                  | ms
> (13 rows)
>
> Using 'ms' seems clearly overkill, but there's precedent for
> timeouts measured in seconds.
>

Agreed, but it is unclear to me in how many of these cases users would
always need to give values in hours or more. In case of
idle_replication_slot_timeout, there is less chance that many people
would like to use the value in seconds in production. Say, tomorrow,
we want to assign some default value to this GUC, it is likely that we
would choose some value in minutes. Based on this thinking, we decided
to keep the unit of this GUC as minutes. But I see the theory of
consistency with a larger number of similar-sounding GUCs and the
developer testing theory to keep this value in seconds. So, if more
people prefer to use the unit as seconds and are not convinced by the
points I made, we should go ahead and change it.

-- 
With Regards,
Amit Kapila.