Re: Remove Deprecated Exclusive Backup Mode

Greetings,

* Christophe Pettus (xof@thebuild.com) wrote:
> > On Feb 24, 2019, at 13:00, Stephen Frost <sfrost@snowman.net> wrote:
> >
> > No, it *hasn't* been the only backup API for a long time- that was only
> > true up until 9.6 was released, since then we've had both, and it's made
> > everything a downright mess because of exactly these arguments.
>
> 9.6 has been out for about 2.5 years.  How long was the old version of pg_start_backup() the only interface?
Considerablylonger. 

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.

> > Yes, it *is* impossible to do safe backups with the existing API.
>
> That's an overstatement.  "The existing interface has failure conditions that are hard to work around" is true.
Saying"it's impossible to do safe backups" implies that no pre-9.6 system has ever been backed up.  If we take that
line,it's just going to create a "Oh, come *on*" reaction from users. 

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.

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.

> > What I'll say
> > is that they'll have over 5 years to adjust those scripts and I don't
> > see an issue with that.
>
> That's not quite the situation.  What they will have is a choice between upgrading, and or their existing scripts
continuingto work.  That choice will start ticking the instant a release without the old interface comes out.  The
back-pressureon upgrading is already very high; this is going to put a lot of installations into a bind, and a lot will
makethe decision not to upgrade because of that. 

That's fine- they can push off upgrading, for as long as 5 years, and
we'll still support them.  That's the model we operate under for
everything, 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*.

> > *ALL* of our APIs are declared non-stable between major releases.
> > That's why we have *major* and *minor* releases.
>
> I note that a word game is being played here.  We're calling pg_start_backup() "an API", as if it is the same as,
say,the GiST C API, but it's a SQL level construct.  SQL level constructs are not promises we need to keep forever, of
course,but they're not the same class of promise as a C API. 

I'm not following here, at all...  We're actually better, historically,
about not changing SQL-level constructs than C-level APIs, but we can
and do still change them, regularly, with every major release- including
making new reserved keywords and other very clearly potentially breaking
changes.

> > Sure, it'd be nice if someone would fix it to list out the problems with
> > the exclusive API, but that requires someone wanting to spend time on
> > it.
>
> I'll take a turn at it.

Just to be clear- I don't agree that simply documenting the issues with
it is a sufficient solution to make us keep it.  I'll certainly continue
to advocate for its removal, but it would be nice for people who are
currently using it to be aware of the issues, so I do think it'd be good
to have the documentation improved in that regard, just make sure to not
invalidate the documentation around non-exclusive backup while you're at
it.

Thanks!

Stephen