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 1nP6MB-00046x-O2 for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Mar 2022 17:32:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nP6MA-0007SX-Kp for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Mar 2022 17:32:14 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nP6MA-0007SO-9V for pgsql-hackers@lists.postgresql.org; Tue, 01 Mar 2022 17:32:14 +0000 Received: from mail-pj1-x1032.google.com ([2607:f8b0:4864:20::1032]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nP6M7-0007YR-VY for pgsql-hackers@lists.postgresql.org; Tue, 01 Mar 2022 17:32:13 +0000 Received: by mail-pj1-x1032.google.com with SMTP id b8so14646715pjb.4 for ; Tue, 01 Mar 2022 09:32:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=vFEwuet5rd36LLP4kAvC4dkUnrlt5twINNjqwK+Shug=; b=L4dPuw3P9kZG57eDiMshTvdWXqMRC978/oDZAgpwZLSjNbFHavx7ZkXVPLGFyPLvvv X+2IuFgcO1dLOtUeKvFQcXQb+o128kKng3QRaW5RbsG3oE3PWZy0cS4i4780JaIZZOUn PpmO7QQrvKkVAFCNk3nCfai+/W5LQ5peZdvhLa+59j4rWHeL63crd8vyPjK7ojPxLLHU Ug8G61ztYqfGRCqiV9GoW0ApJJQL0ps7n8fv+L0ZZN4pTPvclKbn3amWpRQr9GaQeWAD vYwNzgdladU28ZFd/Xc+E1r3hK5184RtKWr6ziVIPh0Cr5mJzPCs7y/+YgKvGUjVqF1q KNCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=vFEwuet5rd36LLP4kAvC4dkUnrlt5twINNjqwK+Shug=; b=ImgvCEOu0D91bXIpQE+JcWIN6ga5qktmwjA6Y6vlhWZVGLGpm0Er6FE6ebr6SI0Wgy ypJeJHKaBTT2i0k1OMG+YZiV6AjHogVc+kGXT0G9+/XObUWNSk4UYGbOnB3uV2axwcL3 dqxj1QOzq++/FIyJEQM8G1YFGt9zs6udZJ3xqrm3e3/r8YQa6dfKC5XlvgM2TTx5igt2 Wi+vraDBE4IZehRa3Mac8F4s0/wFyTBKZntjz1wUkIkMA7K9amlBpwip1DqcqNVqGFzQ sE5If/D8K2FssjiKbIIGT9Q+Sk5v3yI8WTWYVw5NE/j8CHfdSYcq2W/e30BVpFbDiuXC 6RhQ== X-Gm-Message-State: AOAM531WVY9AdQrTMW6zKUfP09Bbbj0HloS5xeqjnr+jLtZFwYNAyX90 LuUy2t3j3T1Dt+3rORCSqdY= X-Google-Smtp-Source: ABdhPJwC3q2KoZqxDy0kr9cf1OlGkk3ngXhxxlWkdqj/dbXXlrrwrPEfgKY+/bFhg0FjUU+vFkVjFA== X-Received: by 2002:a17:90a:4542:b0:1b9:bc2a:910f with SMTP id r2-20020a17090a454200b001b9bc2a910fmr22515925pjm.133.1646155930688; Tue, 01 Mar 2022 09:32:10 -0800 (PST) Received: from nathanxps13 ([50.54.155.70]) by smtp.gmail.com with ESMTPSA id u12-20020a17090a890c00b001b8efcf8e48sm2659914pjn.14.2022.03.01.09.32.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Mar 2022 09:32:10 -0800 (PST) Date: Tue, 1 Mar 2022 09:32:08 -0800 From: Nathan Bossart To: Chapman Flack Cc: David Steele , pgsql-hackers@lists.postgresql.org Subject: Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file Message-ID: <20220301173208.GB1031413@nathanxps13> References: <20220221172306.GA3698472@nathanxps13> <164589413251.1035.2695761148079719188.pgcf@coridan.postgresql.org> <20220226220614.GA673898@nathanxps13> <20220301055100.GA1002387@nathanxps13> <621E4529.1090601@anastigmatix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <621E4529.1090601@anastigmatix.net> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Mar 01, 2022 at 11:09:13AM -0500, Chapman Flack wrote: > 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? My suggestion was to remove it in v15. My impression is that David and Stephen agree, but I could be misinterpreting their responses. > 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. I'm not sure if there's any advantage to kicking the can down the road. At some point, we'll need to break existing backup scripts. Will we be more prepared to do that in v17 than we are now? We could maintain two sets of functions for a few releases and make it really clear in the documentation that pg_start/stop_backup() are going to be removed soon (and always emit a WARNING when they are used). Would that address your concerns? -- Nathan Bossart Amazon Web Services: https://aws.amazon.com