Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nP53y-0000h7-GU for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Mar 2022 16:09:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nP53x-0005RK-4p for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Mar 2022 16:09:21 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nP53w-0005RB-0a for pgsql-hackers@lists.postgresql.org; Tue, 01 Mar 2022 16:09:20 +0000 Received: from anastigmatix.net ([68.171.219.55]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nP53t-0000fp-FJ for pgsql-hackers@lists.postgresql.org; Tue, 01 Mar 2022 16:09:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=anastigmatix.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pGAU7sJ0v4GLhKfTiQ4aRHtznygkXYpbkX4q6qnt/WY=; b=Xc5achb1OO+iM14+zPKHQlX2/I WWWQzCCx+FlE7F5YKAh01lJ5vYRDAuA2jIcxZz6USi5QKS3M+SMA0KsQn4MbL8D9Cs5GZoNs9Vflc Lzm2InRp0IzJNBZKM7yci8vop6BoJfeQTtAEE7TdnvbmSlmD/vQBlHOMXz1lTkIjCdYaIOuACGat5 G643tYtwK4CV5NTObLnAjZrmkyEhvq7n62cnCTudE2+2VvOwN/L7fV8DX0PHj43X4QXMSOhXAJPWj HKfFhV3LHZEUN4ydExKXNdVmD5ZecTDpTrk+SlJgCFsLXDPRWN+Lg/lVUitaLZPv9BiwP1mwSjmZM KR1NIoeg==; Received: from 50-102-16-206.prtg.in.frontiernet.net ([50.102.16.206]:48222) by bay.acenet.us with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1nP53q-007giK-AO; Tue, 01 Mar 2022 11:09:14 -0500 Subject: Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file To: David Steele , Nathan Bossart References: <20220221172306.GA3698472@nathanxps13> <164589413251.1035.2695761148079719188.pgcf@coridan.postgresql.org> <20220226220614.GA673898@nathanxps13> <20220301055100.GA1002387@nathanxps13> Cc: pgsql-hackers@lists.postgresql.org From: Chapman Flack X-Enigmail-Draft-Status: N1110 Message-ID: <621E4529.1090601@anastigmatix.net> Date: Tue, 1 Mar 2022 11:09:13 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bay.acenet.us X-AntiAbuse: Original Domain - lists.postgresql.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - anastigmatix.net X-Get-Message-Sender-Via: bay.acenet.us: authenticated_id: chap@anastigmatix.net X-Authenticated-Sender: bay.acenet.us: chap@anastigmatix.net X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 03/01/22 09:44, David Steele wrote: > Personally, I am in favor of removing it. We change/rename > functions/tables/views when we need to, and this happens in almost every > release. For clarification, is that a suggestion to remove the 'exclusive' parameter in some later release, after using this release to default it to false and reject calls with true? I can get behind that proposal, even if we don't have a practical way to add the warning I suggested. I'd be happier with the warning, but can live without it. Release notes can be the warning. That way, at least, there would be a period of time where procedures that currently work (by passing exclusive => false) would continue to work, and could be adapted as time permits by removing that argument, with no behavioral change. The later release removing the argument would then break only procedures that had never done so. That's comparable to what's proposed for this release, which will only break procedures that have never migrated away from exclusive mode despite the time and notice to do so. That seems ok to me. Regards, -Chap