Re: Remove Deprecated Exclusive Backup Mode

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: David Steele <david(at)pgmasters(dot)net>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Stephen Frost <sfrost(at)snowman(dot)net>, Adrien NAYRAT <adrien(dot)nayrat(at)anayrat(dot)info>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Remove Deprecated Exclusive Backup Mode
Date: 2019-02-26 12:54:12
Message-ID: CA+TgmoaWKrgUf8bJ1C8n5YA8ndD_faEWH_XXfRpZD--rFWfUcA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 26, 2019 at 1:49 AM David Steele <david(at)pgmasters(dot)net> wrote:
> The operator still has a decision to make, manually, just as they do
> now. The wrong decision may mean a corrupt database.
>
> Here's the scenario:
>
> 1) They do a restore, forget to rename backup_label.pending.
> 2) Postgres won't start, which is the same action we take now.
> 3) The user is not sure what to do, rename or delete? They delete, and
> the cluster is corrupted.
>
> Worse, they have scripted the deletion of backup_label so that the
> cluster will restart on crash. This is the recommendation from our
> documentation after all. If that script runs after a restore instead of
> a crash, then the cluster will be corrupt -- silently.

Sure, that's true. On the other hand, it's not like someone can't
manage to use the non-exclusive mode and fail to drop the backup_label
and tablespace_map files into the right places. This procedure is
tedious and error-prone no matter which way you do it, which is one
reason I don't believe that the exclusive backup method is nearly as
bad as you're making it out to be.

Mind you, I'm not really defending the proposal to add a new backup
mode along the likes Fujii Masao is proposing. I don't think the
situation will be made less error-prone by having three ways to do it
instead of two. But I think we probably would've been happier if we'd
designed it the way he's now proposing in the first place, instead of
the way we actually did.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2019-02-26 12:57:14 Re: pgbench MAX_ARGS
Previous Message Eugen Konkov 2019-02-26 12:48:46 Re: BUG #15646: Inconsistent behavior for current_setting/set_config