> On Feb 24, 2019, at 12:00, Stephen Frost <sfr...@snowman.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
x...@thebuild.com
