Re: Remove Deprecated Exclusive Backup Mode

> On Feb 24, 2019, at 13:44, Stephen Frost  wrote:
> 
> Right, and PG12 will be out for another *5* years beyond that, meaning
> people will have had 8.5 years to move from the exclusive API to the
> non-exclusive one.

The thing is that for 90% of installations, the clock will start ticking when the deprecation.  Until then, most of them are not going to feel any pressure to make the change.  Most installations have a lot of other things on their minds.  They have the option of not upgrading, and that will be the option a lot of them take.

> Every one of the exclusive backups that was taken wasn't *safe*, and a
> crash during any of them (which we've certainly heard plenty about
> through various support channels over the years...) would have resulted
> in a failure to properly restart.

Most installations don't routinely encounter this.  I know it happens, and it is definitely a problem, but the field is not strewn with corpses here.  The new interface is unquestionably an improvement, but let's not get our messaging amped up to the point that it hurts our credibility.

> No, I'm not saying that such backups are corrupted, *that* is an
> overstatement, but it isn't actually what I'm saying, just a strawman
> you've come up with to argue against.

That may not be what you are saying, but statements like "it *is* impossible to do safe backups with the existing API" will be heard that way.  Let's keep the messaging we give users accurate.

> this isn't any different in that regard and I don't have
> sympathy for people who insist on saying that *this*, just *this* one
> API of *all* the ones we have simply *can't* be changed *ever*.

Sure, we can change anything.  It's whether this particular deprecation is a good idea.

> I'm not following here, at all...  We're actually better, historically,
> about not changing SQL-level constructs than C-level APIs

That's my point.  Calling this an "API" makes the change sound more routine than it is.  It's an "API" that a *lot* of installations depend on.

> I don't agree that simply documenting the issues with
> it is a sufficient solution to make us keep it.

Understood, but I think we need to document it no matter what.
--
-- Christophe Pettus
   xof@thebuild.com