Re: Remove Deprecated Exclusive Backup Mode
Stephen Frost <sfrost@snowman.net>
From: Stephen Frost <sfrost@snowman.net>
To: Christophe Pettus <xof@thebuild.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Fujii Masao <masao.fujii@gmail.com>, David Steele <david@pgmasters.net>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-02-24T20:00:07Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Remove exclusive backup mode
- 39969e2a1e4d 15.0 landed
Greetings, * Christophe Pettus (xof@thebuild.com) wrote: > > On Feb 22, 2019, at 15:18, Stephen Frost <sfrost@snowman.net> wrote: > > Getting a solid and resiliant backup to work from a shell script is, imv > > anyway (though I might have a bit of experience, having tried numerous > > times myself and then realizing that it just isn't practical...), a > > downright fool's errand. > > The reality, though, is that there are a lot of organizations who have invested time and effort into getting a backup strategy working using the existing APIs, and there will be quite a bit of pushback against the version in which the existing exclusive API is removed. Do they realize how that existing backup strategy is flawed? I doubt it, and when they discover how it's broken, I don't think they're going to be thanking us for letting them continue to use it. > Some of those will be able to move to non-exclusive backups easily; others won't. For the ones that can't move easily, the reaction will not be, "PostgreSQL version x has a safer backup API"; it will be "PostgreSQL version x broke our backups, so we're not upgrading to it." 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. They aren't required to upgrade immediately- we provide 5 *years* of support for major versions which we release, and we're going to give advance warning of this change that's even beyond that 5 years. I have essentially zero sympathy for organizations which refuse to allocate even the bit of time necessary to address this change for over 5+ years. > Rather than deprecate the existing API, I'd rather see the documentation updated to discuss the danger cases. 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). That really isn't a good place to be in. Thanks! Stephen