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