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 1nP8bd-0001Ou-90 for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Mar 2022 19:56:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nP8bc-00043V-62 for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Mar 2022 19:56:20 +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 1nP8bb-00042P-T2 for pgsql-hackers@lists.postgresql.org; Tue, 01 Mar 2022 19:56:19 +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 1nP8bZ-0002VL-QA for pgsql-hackers@lists.postgresql.org; Tue, 01 Mar 2022 19:56: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=4CFE7CPZdOjj3t1qCiCiR30EwHGhzcAn5/W60yZIP0M=; b=YxE2Z5GS3p8gxxE50kabNsPVc7 QBzvOug2BAmNaWYYjaKAUeqeNfD+mib56M7dT+JD1RkfeI/wbzuhjEA2x64rOxMx550oqiPfz6Z/3 qbDJiDx5/XkOJ7kGwilSX0WsTmrMCexDV0yEJOfZzyo0ySvw4BCyZsPuXutzCQvEx9GKeS0qG9hqK 4yWC+ahKADIzmc4uXPFPN/CkKRHGHCJ5CdB6QQ8ttXEl9TjSRqH2IiydyQxVvhaY71foyp8GWq5AW yGAw5OlNBdRdXKtQBeQtiFlMPr4cvMY0j6rbzmxrftzLTaAzsjZKOMOZcFi1MAF1Yvu/IHPIA1cqG 0BdozRGg==; Received: from 50-102-16-206.prtg.in.frontiernet.net ([50.102.16.206]:48309) by bay.acenet.us with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1nP8bW-00DxS5-Lm; Tue, 01 Mar 2022 14:56:15 -0500 Subject: Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file To: Stephen Frost References: <20220221172306.GA3698472@nathanxps13> <164589413251.1035.2695761148079719188.pgcf@coridan.postgresql.org> <20220226220614.GA673898@nathanxps13> <20220301055100.GA1002387@nathanxps13> <621E4529.1090601@anastigmatix.net> <20220301173208.GB1031413@nathanxps13> <1f685b3a-7ec2-825e-bb2b-d87d78ad5bd9@pgmasters.net> <621E6C2E.2050801@anastigmatix.net> <20220301191441.GW10577@tamriel.snowman.net> Cc: David Steele , Nathan Bossart , pgsql-hackers@lists.postgresql.org From: Chapman Flack X-Enigmail-Draft-Status: N1110 Message-ID: <621E7A5C.1030203@anastigmatix.net> Date: Tue, 1 Mar 2022 14:56:12 -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: <20220301191441.GW10577@tamriel.snowman.net> Content-Type: text/plain; charset=windows-1252 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 14:14, Stephen Frost wrote: >> There can't really be many teams out there thinking "we'll just ignore >> these scripts forever, and nothing bad will happen." They all know they'll >> have to do stuff sometimes. But it matters how we allow them to schedule it. > > We only make these changes between major versions. That's as much as we > should be required to provide. It's an OSS project, so I guess we're not required to provide anything. But in the course of this multi-release exclusive to non-exclusive transition, we already demonstrated, in 7117685, that we can avoid inflicting immediate breakage when there's nothing in our objective that inherently requires it, and avoiding it is relatively easy. I can't bring myself to think that was a bad precedent. Now, granted, the difference between the adaptations being required then and the ones required now is that those required both: changes to some function calls, and corresponding changes to how the scripts handled label and tablespace files. Here, it's only a clerical update to some function calls. So if I'm outvoted here and the reason is "look, a lighter burden is involved this time than that time", then ok. I would rather bow to that argument on the specific facts of one case than abandon the precedent from 7117685 generally. Regards, -Chap