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 1qlxYC-0052Ft-SH for pgsql-hackers@arkaria.postgresql.org; Thu, 28 Sep 2023 20:23:56 +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 1qlxYB-00G1yE-45 for pgsql-hackers@arkaria.postgresql.org; Thu, 28 Sep 2023 20:23:55 +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 1qlxYA-00G1y6-Pt for pgsql-hackers@lists.postgresql.org; Thu, 28 Sep 2023 20:23:54 +0000 Received: from mail.thelabyrinth.net ([45.56.70.56]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qlxY7-0089X3-Pa for pgsql-hackers@lists.postgresql.org; Thu, 28 Sep 2023 20:23:54 +0000 Received: from [10.5.0.2] (unknown [45.14.195.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: dsteele) by mail.thelabyrinth.net (Postfix) with ESMTPSA id C73FE54661; Thu, 28 Sep 2023 20:23:48 +0000 (UTC) Message-ID: <4f94351c-24e2-cf32-82d3-1e1bf89a0f5e@pgmasters.net> Date: Thu, 28 Sep 2023 16:23:42 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: Requiring recovery.signal or standby.signal when recovering with a backup_label To: Kyotaro Horiguchi , michael@paquier.xyz Cc: pgsql-hackers@lists.postgresql.org, zxwsbg12138@gmail.com, david.zhang@highgo.ca References: <20230928.125851.2051261991058034791.horikyota.ntt@gmail.com> Content-Language: en-US From: David Steele In-Reply-To: <20230928.125851.2051261991058034791.horikyota.ntt@gmail.com> 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 9/27/23 23:58, Kyotaro Horiguchi wrote: > At Fri, 10 Mar 2023 15:59:04 +0900, Michael Paquier wrote in >> My apologies for the long message, but this deserves some attention, >> IMHO. >> >> So, any thoughts? > > Sorry for being late. However, I agree with David's concern regarding > the unnecessary inconvenience it introduces. I'd like to maintain the > functionality. After some playing around, I find I agree with Michael on this, i.e. require at least standby.signal when a backup_label is present. According to my testing, you can preserve the "independent server" functionality by setting archive_command = /bin/false. In this case the timeline is not advanced and recovery proceeds from whatever is available in pg_wal. I think this type of recovery from a backup label without a timeline change should absolutely be the exception, not the default as it seems to be now. If the server is truly independent, then the timeline change is not important. If the server is not independent, then the timeline change is critical. So overall, +1 for Michael's patch, though I have only read through it and not tested it yet. One comment, though, if we are going to require recovery.signal when backup_label is present, should it just be implied? Why error and force the user to create it? Regards, -David