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 1nOvPk-0001xX-Et for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Mar 2022 05:51:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nOvPj-0005kR-6P for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Mar 2022 05:51:11 +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 1nOvPi-0005iZ-RV for pgsql-hackers@lists.postgresql.org; Tue, 01 Mar 2022 05:51:10 +0000 Received: from mail-pg1-x52b.google.com ([2607:f8b0:4864:20::52b]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nOvPc-0001wp-8f for pgsql-hackers@lists.postgresql.org; Tue, 01 Mar 2022 05:51:09 +0000 Received: by mail-pg1-x52b.google.com with SMTP id t14so10622390pgr.3 for ; Mon, 28 Feb 2022 21:51:04 -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=tn+kECfk8yUrXKvKhjNFbc/z8d3EFVtQh4yQdzc9RvA=; b=G7BErzVco4eJFhPqclip7wJLjkpGbMlWHPMQF8gWVa8E1shA1Lkqn6Q2tddMXRwy7B jOxOJwrePyExuxdqG3NkswgijBP3vMh6qDVaRm79GvJ6XbgOaVy13eWnAhCuorPmSuPd uL9NnR5oP1LdbfGRl+JFa2hE0qNuRJ+ge+yuhhxF8LVh+knP52yFC+/Pp8wpwY7y4/ws c5CAk17C1Qyif7ydPomcwuw5h6yrv5Xl+VQyUBu2jMFqTNkoYLD1/0I5wfujqPde6JUc 3eKYmuavu6RacZrnFEVPlfJwCMJeyDvovMzVEtdpD/FXh9ArKS/9OyMLse8stdZD60Cf eYrA== 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=tn+kECfk8yUrXKvKhjNFbc/z8d3EFVtQh4yQdzc9RvA=; b=c7uHqNXxvVk14gCU0Upzdxuzl1uQXSQ0tZUyGR9TWd1VT3+CqR0OpV85cqZbKTCdXu bwDtr1EdpZiHLf+q8Oj/DyHhH/ndfZm7Porml4Enl+f2+6tfJvIuY7aEpVpl6HCUr7R8 57Cuw4BE3iA4tNvxkmvuHbF3ERdlUq+SJWVIZ3JXODKkqrH+GnQPbbP2mvxtWafmbDR6 Ow9dK7YXhYYj70uaP8p7BuFk7KPdEtO7EKLPR4rI0tD2CnPyZv/2b1/AyeCQxpPZ3VLb XI9sLP5j25cvQ6tkaTnRiIzW577rTWKx94GfZG9ZTaHashCH/0gmc8dpgJWOecwKLipq yP2Q== X-Gm-Message-State: AOAM531/3XReq9beHwlcOTO/WqDN5y1G9UfTm2PFHCdZkJfUBjxGYM3e FNhkNtPRBbmD6mySxT2lT/k= X-Google-Smtp-Source: ABdhPJx0fE5Aqu0VGDZzzoqrS9J+Og6qpgNRdP6h58Z3ca/ccJd1v4SohJnhf1AiLOHlekwomkVq3g== X-Received: by 2002:a65:4d03:0:b0:375:7eca:b63a with SMTP id i3-20020a654d03000000b003757ecab63amr20222997pgt.141.1646113863280; Mon, 28 Feb 2022 21:51:03 -0800 (PST) Received: from nathanxps13 ([50.54.155.70]) by smtp.gmail.com with ESMTPSA id b21-20020a056a000cd500b004e1e0d3ed18sm15785499pfv.2.2022.02.28.21.51.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Feb 2022 21:51:02 -0800 (PST) Date: Mon, 28 Feb 2022 21:51:00 -0800 From: Nathan Bossart To: Chapman Flack Cc: pgsql-hackers@lists.postgresql.org, David Steele Subject: Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file Message-ID: <20220301055100.GA1002387@nathanxps13> References: <20220221172306.GA3698472@nathanxps13> <164589413251.1035.2695761148079719188.pgcf@coridan.postgresql.org> <20220226220614.GA673898@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220226220614.GA673898@nathanxps13> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, Feb 26, 2022 at 02:06:14PM -0800, Nathan Bossart wrote: > On Sat, Feb 26, 2022 at 04:48:52PM +0000, Chapman Flack wrote: >> Assuming the value is false, so no error is thrown, is it practical to determine >> from flinfo->fn_expr whether the value was defaulted or supplied? If so, I would >> further suggest reporting a deprecation WARNING if it was explicitly supplied, >> with a HINT that the argument can simply be removed at the call site, and will >> become unrecognized in some future release. > > This is a good point. I think I agree with your proposed changes. I > believe it is possible to add a deprecation warning only when 'exclusive' > is specified. If anything, we can create a separate function that accepts > the 'exclusive' parameter and that always emits a NOTICE or WARNING. I've spent some time looking into this, and I haven't found a clean way to emit a WARNING only if the "exclusive" parameter is supplied (and set to false). AFAICT flinfo->fn_expr doesn't tell us whether the parameter was supplied or the default value was used. I was able to get it working by splitting pg_start_backup() into 3 separate internal functions (i.e., pg_start_backup_1arg(), pg_start_backup_2arg(), and pg_start_backup_3arg()), but this breaks calls such as pg_start_backup('mylabel', exclusive => false), and it might complicate privilege management for users. Without a WARNING, I think it will be difficult to justify removing the "exclusive" parameter in the future. We would either need to leave it around forever, or we would have to risk unnecessarily breaking some working backup scripts. I wonder if we should just remove it now and make sure that this change is well-documented in the release notes. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com