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 1qwMvs-00BKBm-QU for pgsql-hackers@arkaria.postgresql.org; Fri, 27 Oct 2023 13:31:24 +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 1qwMvq-00FXyh-M4 for pgsql-hackers@arkaria.postgresql.org; Fri, 27 Oct 2023 13:31:22 +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 1qwMvq-00FXyY-Cl for pgsql-hackers@lists.postgresql.org; Fri, 27 Oct 2023 13:31:22 +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 1qwMvi-0037Jp-Q0 for pgsql-hackers@lists.postgresql.org; Fri, 27 Oct 2023 13:31:21 +0000 Received: from [10.5.0.2] (unknown [107.175.102.154]) (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 809125478A; Fri, 27 Oct 2023 13:31:11 +0000 (UTC) Message-ID: <0f25d737-64c8-4ef3-9873-f2d4f44b1431@pgmasters.net> Date: Fri, 27 Oct 2023 09:31:10 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Requiring recovery.signal or standby.signal when recovering with a backup_label Content-Language: en-US To: Michael Paquier Cc: Kyotaro Horiguchi , pgsql-hackers@lists.postgresql.org, zxwsbg12138@gmail.com, david.zhang@highgo.ca References: <20230928.125851.2051261991058034791.horikyota.ntt@gmail.com> <4f94351c-24e2-cf32-82d3-1e1bf89a0f5e@pgmasters.net> From: David Steele In-Reply-To: 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 10/27/23 03:22, Michael Paquier wrote: > On Mon, Oct 16, 2023 at 02:54:35PM +0900, Michael Paquier wrote: >> On Sat, Oct 14, 2023 at 03:45:33PM -0400, David Steele wrote: >>> On 9/28/23 19:59, Michael Paquier wrote: >>>> Another idea I had was to force the creation of recovery.signal by >>>> pg_basebackup even if -R is not used. All the reports we've seen with >>>> people getting confused came from pg_basebackup that enforces no >>>> configuration. >>> >>> This change makes it more obvious if configuration is missing (since you'll >>> get an error), however +1 for adding this to pg_basebackup. >> >> Looking at the streaming APIs of pg_basebackup, it looks like this >> would be a matter of using bbstreamer_inject_file() to inject an empty >> file into the stream. Still something seems to be off once >> compression methods are involved.. Hmm. I am not sure. Well, this >> could always be done as a patch independant of this one, under a >> separate discussion. There are extra arguments about whether it would >> be a good idea to add a recovery.signal even when taking a backup from >> a standby, and do that only in 17~. > > Hmm. On this specific point, it would actually be much simpler to > force recovery.signal to be in the contents streamed to a BASE_BACKUP. That sounds like the right plan to me. Nice and simple. > This does not step on your proposal at [1], though, because you'd > still require a .signal file for recovery as far as I understand :/ > > [1]: https://www.postgresql.org/message-id/2daf8adc-8db7-4204-a7f2-a7e94e2bfa4b@pgmasters.net Yes. > Would folks be OK to move on with the patch of this thread at the end? > I am attempting a last-call kind of thing. I'm still +1 for the patch as it stands. Regards, -David