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 1uXh9p-00DHj5-CB for pgsql-bugs@arkaria.postgresql.org; Fri, 04 Jul 2025 14:12:53 +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 1uXh9m-00115S-I8 for pgsql-bugs@arkaria.postgresql.org; Fri, 04 Jul 2025 14:12:51 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uXh9m-00115G-9r for pgsql-bugs@lists.postgresql.org; Fri, 04 Jul 2025 14:12:50 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uXh9j-005hwt-2L for pgsql-bugs@lists.postgresql.org; Fri, 04 Jul 2025 14:12:50 +0000 Received: from [192.168.11.9] (p1696134-ipoe.ipoe.ocn.ne.jp [118.0.93.133]) by oss.nttdata.com (Postfix) with ESMTPSA id AD76961B9D; Fri, 4 Jul 2025 23:12:40 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at oss.nttdata.com Message-ID: <30e91649-06dd-453e-8658-5f4acd03a3bd@oss.nttdata.com> Date: Fri, 4 Jul 2025 23:12:40 +0900 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Unexpected behavior when setting "idle_replication_slot_timeout" To: Nisha Moond , Gunnar Morling Cc: pgsql-bugs@lists.postgresql.org References: Content-Language: en-US From: Fujii Masao In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2025/07/04 21:14, Nisha Moond wrote: > On Fri, Jul 4, 2025 at 4:35 PM Gunnar Morling > 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