Re: Remove Deprecated Exclusive Backup Mode

Greetings,

* Christophe Pettus (xof@thebuild.com) wrote:
> > On Feb 24, 2019, at 13:44, Stephen Frost <sfrost@snowman.net> 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
themare 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. 

Just to be clear- it was *already* deprecated, we are just talking here
about making that more clear/obvious.

And, again, they're welcome to not upgrade for as long as they'd like,
frankly, but we'll only provide back-patches for 5 years.

> > 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
isnot strewn with corpses here.  The new interface is unquestionably an improvement, but let's not get our messaging
ampedup 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.

You say above that the new interface is unquestionably an improvement
and here say that we shouldn't deprecate the old one in favor of it
(even though we actually already have... but that's beside the point I'm
trying to make here), so what you're advocating for is that we keep an
old and known broken interface that we know causes real issues even
after we've developed a new and unquestionably better one.

For my 2c, I think keeping the old interface around at all was a mistake
from the start, just the same as things like pg_user have been kept
around forever because of fear of breaking things, even as we rip out
the recovery.conf file or rename tons of things in the catalog across
major versions.

I really, honestly, believe what we need to *stop* doing is trying to
drag along support for old/deprecated interfaces after we've introduced
new ones, thus avoiding these arguments and the time spent on them, and
the time spent dealing with implementing and documenting new APIs around
old ones.  The only thing it seems to unquestionably do is make us argue
about when we are going to *finally* rip out the old/deprecated API (or
interface, or whatever you want to call it).

This is the new "should we call it PG 10.0 or PG 9.7 this time?"
argument, all over again...

> > 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*
ofinstallations depend on. 

A lot of them depended on pg_wal being named pg_xlog too, but we seem to
have managed reasonably well through that, not to mention all the
catalog changes that caused issues for monitoring, etc.

> > 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.

Sure, go for it.

Thanks!

Stephen