Re: Remove Deprecated Exclusive Backup Mode

> On Feb 24, 2019, at 12:00, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
> Do they realize how that existing backup strategy is flawed?

Undoubtedly, some do, some don't. However, given that it has been the *only* backup API for a very long time, many organizations have spent a lot of time closing all of the holes.

It's not impossible to do safe backups with the existing API. Unquestionably, there are installations doing backups that might end up with a silently badly one, but it's entirely possible to do that unsafely (in many of the same ways) with the non-exclusively API.

The installations that need to fix the scripts are also exactly the ones that can't use pg_basebackup or another pre-packaged solution, usually because they have a specific way of taking the file system copy (SAN snapshot, etc.) that those don't support.

> We don't cater to this line of argument when it comes to breaking
> changes in the backend, or when we break monitoring scripts, and I don't
> see a reason why we should do so here.

Those cases are not analogous.

1. Backend APIs are declared non-stable, and do not have a wide audience compared to backing up the database.
2. Monitoring scripts, while important, are not as critical as the backup system. (And, in fact, I didn't agree with breaking those views either, but that's another discussion.)

> Ok, then please do so, and please be prepared to continue to maintain
> the documentation of both methods moving forward, because others have
> tried and have (rightfully, in my opinion) decided that it's frankly not
> worth the effort and ultimately just terribly confusing for users that
> we have these two different backup methods and even just updating the
> documentation for one or the other is downright painful (to the point
> that people litterally give up on it).

We're going to have to do that anyway. For as long as we are maintaining the documentation on a version that has both APIs, we're going to have to say, "Don't use this one, and *here's why*." Saying, "Don't use this one because we said so" when it is an API of long standing that works just as it always did isn't going to cut it.

--
-- Christophe Pettus
xof(at)thebuild(dot)com