Re: Remove Deprecated Exclusive Backup Mode
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: David Steele <david@pgmasters.net>
Cc: Fujii Masao <masao.fujii@gmail.com>, Laurenz Albe <laurenz.albe@cybertec.at>, Stephen Frost <sfrost@snowman.net>, Adrien NAYRAT <adrien.nayrat@anayrat.info>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-02-26T04:51: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
On Mon, Feb 25, 2019 at 08:17:27PM +0200, David Steele wrote: > Here's the really obvious bad thing: if users do not update their procedures > and we ignore backup_label.pending on startup then they will end up with a > corrupt database because it will not replay from the correct checkpoint. If > we error on the presence of backup_label.pending then we are right back to > where we started. Not really. If we error on backup_label.pending, we can make the difference between a backend which has crashed in the middle of an exclusive backup without replaying anything and a backend which is started based on a base backup, so an operator can take some action to see what's wrong with the server. If you issue an error, users can also see that their custom backup script is wrong because they forgot to rename the flag after taking a backup of the data folder(s). The real pain point about the non-exclusive APIs is really that we need to keep the connection opened, which can be done easily using drivers like psycopg2 or such, still that's far from straight-forward for the average enterprise user, and it can be hard for some companies to complicate a software stack with more external dependencies. So yes, while I can see the long-term benefits of non-exclusive backups, they are much more complicated to use than exclusive backups. -- Michael