Re: Unexpected behavior when setting "idle_replication_slot_timeout"
От | Tom Lane |
---|---|
Тема | Re: Unexpected behavior when setting "idle_replication_slot_timeout" |
Дата | |
Msg-id | 474268.1751731988@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Unexpected behavior when setting "idle_replication_slot_timeout" (Gunnar Morling <gunnar.morling@googlemail.com>) |
Ответы |
Re: Unexpected behavior when setting "idle_replication_slot_timeout"
Re: Unexpected behavior when setting "idle_replication_slot_timeout" Re: Unexpected behavior when setting "idle_replication_slot_timeout" |
Список | pgsql-bugs |
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. regards, tom lane
В списке pgsql-bugs по дате отправления: