On Tue, Feb 26, 2019 at 1:49 AM David Steele <david@pgmasters.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