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 1uXjCx-00DfFG-QN for pgsql-bugs@arkaria.postgresql.org; Fri, 04 Jul 2025 16:24:15 +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 1uXjCv-001zwI-0f for pgsql-bugs@arkaria.postgresql.org; Fri, 04 Jul 2025 16:24:13 +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 1uXjCu-001zw4-OP for pgsql-bugs@lists.postgresql.org; Fri, 04 Jul 2025 16:24:13 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by makus.postgresql.org with smtp (Exim 4.96) (envelope-from ) id 1uXjCr-005ZUf-22 for pgsql-bugs@lists.postgresql.org; Fri, 04 Jul 2025 16:24:11 +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 B98C661A52; Sat, 5 Jul 2025 01:24:06 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at oss.nttdata.com Message-ID: Date: Sat, 5 Jul 2025 01:24:06 +0900 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Unexpected behavior when setting "idle_replication_slot_timeout" Content-Language: en-US To: Laurenz Albe , Nisha Moond , Gunnar Morling Cc: pgsql-bugs@lists.postgresql.org References: <30e91649-06dd-453e-8658-5f4acd03a3bd@oss.nttdata.com> <686577f2379e4b978803e72746dcf0dd7baf3937.camel@cybertec.at> From: Fujii Masao In-Reply-To: <686577f2379e4b978803e72746dcf0dd7baf3937.camel@cybertec.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2025/07/05 1:07, Laurenz Albe wrote: > On Sat, 2025-07-05 at 00:22 +0900, Fujii Masao wrote: >> On 2025/07/04 23:12, Fujii Masao wrote: >>> 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. >> >> Attached patch changes unit of idle_replication_slot_timeout to seconds. > > -1 > > I think that the reason that several users tried to set it it less than a minute > is that they were trying to test the feature and didn't want to wait long. > I cannot imagine that anybody will want to abandon a standby server just > because it is idle for more than 30 seconds. Maybe. But changing the unit to seconds doesn't make things worse, does it? It still allows users to set values greater than 1 minute, and also less than 1 minute for debugging or testing purposes, if needed. Or are you suggesting we should disallow values below 1 minute? Regards, -- Fujii Masao NTT DATA Japan Corporation