> 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.
> 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'simpossible to do safe backups" implies that no pre-9.6 system has ever been backed up. If we take that line, it's
justgoing to create a "Oh, come *on*" reaction from users.
> 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.
> *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,
theGiST 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.
> 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.
--
-- Christophe Pettus
xof@thebuild.com