Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uY5Vt-000wC7-Ql for pgsql-bugs@arkaria.postgresql.org; Sat, 05 Jul 2025 16:13:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uY5Vq-007Y1W-FE for pgsql-bugs@arkaria.postgresql.org; Sat, 05 Jul 2025 16:13:15 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uY5Vq-007Y1O-6l for pgsql-bugs@lists.postgresql.org; Sat, 05 Jul 2025 16:13:14 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uY5Vp-005jcH-0I for pgsql-bugs@lists.postgresql.org; Sat, 05 Jul 2025 16:13:13 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 565GD8dq474269; Sat, 5 Jul 2025 12:13:08 -0400 From: Tom Lane To: "David G. Johnston" cc: Fujii Masao , Amit Kapila , Laurenz Albe , Nisha Moond , Gunnar Morling , "pgsql-bugs@lists.postgresql.org" Subject: Re: Unexpected behavior when setting "idle_replication_slot_timeout" In-reply-to: <472687.1751731008@sss.pgh.pa.us> References: <30e91649-06dd-453e-8658-5f4acd03a3bd@oss.nttdata.com> <686577f2379e4b978803e72746dcf0dd7baf3937.camel@cybertec.at> <70b183fb-f66e-40d8-b0de-be8c1052fa93@oss.nttdata.com> <472687.1751731008@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Sat, 05 Jul 2025 11:56:48 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <474267.1751731988.1@sss.pgh.pa.us> Date: Sat, 05 Jul 2025 12:13:08 -0400 Message-ID: <474268.1751731988@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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