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 1ms6Ht-00039V-Fr for pgsql-hackers@arkaria.postgresql.org; Tue, 30 Nov 2021 16:47:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ms6Hs-0005CC-CN for pgsql-hackers@arkaria.postgresql.org; Tue, 30 Nov 2021 16:47:24 +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 1ms6Hr-0005C3-W2 for pgsql-hackers@lists.postgresql.org; Tue, 30 Nov 2021 16:47:24 +0000 Received: from mail-wm1-x32b.google.com ([2a00:1450:4864:20::32b]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ms6Hp-0008WN-3k for pgsql-hackers@postgresql.org; Tue, 30 Nov 2021 16:47:22 +0000 Received: by mail-wm1-x32b.google.com with SMTP id r9-20020a7bc089000000b00332f4abf43fso13078168wmh.0 for ; Tue, 30 Nov 2021 08:47:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20210112.gappssmtp.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=lRT3dU2O5YDqXjsGpTcsnPb+TroP7+hLuFhTsEqC/yE=; b=fo/KoIpbE134gESR9pUajumcrVJxE87hkFOxPkgCdKkkp8oCAwLaKI7lDcZpiY1+cN fyM+uBqSsoAIpTfYKeHoD7jIZRvNKPEAE6gNgeEfq8QTf+VOa2IUEJ6Qg6rqqQg5uhsy 9bWnLvASREOcdRIPY7IeDAdyx1MtUYi20YJToiyhJL+CXkkmkvmwHieUfj/BCPxGTtFN IeiFshaX+Wgo28nk9TMZXXML2Umwbc0Tf/Bw4/sHvuexxJ+1D8812xTKrS9QuvwYYGMb pahB17DbBEs7A77zhKz/S5Ufqbzxym/jMuy9KQ5+Xsps/fQ+d+/zGz/T7ZXnDY5UofsW llbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=lRT3dU2O5YDqXjsGpTcsnPb+TroP7+hLuFhTsEqC/yE=; b=BSPt+hy7InWGrMWGRLncpgiDcGe2+6n5gcuYrUC855QBcTBNsWL/HmsZkZ/2yh6tmv BtHlJyEXEubhH0q1sTizf1Lv/74RQ5mvC56FEohSHvGVxg2KhQXrEWe83irbYKm/94JB y2JLKWLEtn/qoO11JERCjxq9xyOI7pHyxVvz1rOZUr83x+noetBXaehWbOJ5dmHO/GhX /qsFdo+MzjDrJqWSlfE3MEHpZcq5+Bg52mzc0L513FXyLo1wLJlVHmXEgCKh6H5MYdWD XafyKxPRdsQS4Ukd4MWBgmAwjvqY1yTD9Z+lGyROwjDIz7W2uPmsq0E+jzxQ3rPVdSK+ g/Ig== X-Gm-Message-State: AOAM530sFe5IIQoXD4F2Qy2qIjuEit14o9mHBL7tPms5SCEAwzI0/mk2 db+0EAY3aHSct24Rig2lkPPWLQ== X-Google-Smtp-Source: ABdhPJwiJUVWqEYEqPuPQ8zaPbOvqkH+JqPR6c80Fqm70w8/GxeWvI8zwNECSd9Py6KQcGvWrvePFA== X-Received: by 2002:a7b:c452:: with SMTP id l18mr67363wmi.46.1638290839148; Tue, 30 Nov 2021 08:47:19 -0800 (PST) Received: from localhost.localdomain (dynamic-eao4yn7curxsp9iwo-pd01.res.v6.highway.a1.net. [2001:871:5e:1de6:4b1e:f3:4b01:40f8]) by smtp.gmail.com with ESMTPSA id t16sm10221883wrn.49.2021.11.30.08.47.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Nov 2021 08:47:18 -0800 (PST) Message-ID: <3404870c1a921bafbcd168c098088981fe082ab1.camel@cybertec.at> Subject: Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file From: Laurenz Albe To: Stephen Frost , Tom Lane Cc: Michael Paquier , SATYANARAYANA NARLAPURAM , Pg Hackers Date: Tue, 30 Nov 2021 17:47:18 +0100 In-Reply-To: <20211130142042.GR26257@tamriel.snowman.net> References: <417711.1637940660@sss.pgh.pa.us> <20211130142042.GR26257@tamriel.snowman.net> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 (3.40.4-2.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, 2021-11-30 at 09:20 -0500, Stephen Frost wrote: > Greetings, > > * Tom Lane (tgl@sss.pgh.pa.us) wrote: > > Michael Paquier writes: > > > On Thu, Nov 25, 2021 at 06:19:03PM -0800, SATYANARAYANA NARLAPURAM wrote: > > > > If we are keeping it then why not make it better? > > > > > Well, non-exclusive backups are better by design in many aspects, so I > > > don't quite see the point in spending time on something that has more > > > limitations than what's already in place. > > > > IMO the main reason for keeping it is backwards compatibility for users > > who have a satisfactory backup arrangement using it.  That same argument > > implies that we shouldn't change how it works (at least, not very much). > > There isn't a satisfactory backup approach using it specifically because > of this issue, hence why we should remove it to make it so users don't > run into this. There is a satisfactory approach, as long as you are satisfied with manually restarting the server if it crashed during a backup. > I don't find the reasons brought up to continue to support exclusive > backup to be at all compelling and the lack of huge issues with the new > way restore works to make it abundently clear that we can, in fact, > remove exclusive backup in a major version change without the world > coming down. I guess the lack of hue and cry was at least to a certain extent because the exclusive backup API was deprecated, but not removed. Yours, Laurenz Albe