Re: Remove Deprecated Exclusive Backup Mode
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: David Steele <david@pgmasters.net>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-02-22T18:10:25Z
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 Fri, Feb 22, 2019 at 12:35 PM Fujii Masao <masao.fujii@gmail.com> wrote: > -1 for the removal. I think that there are still many users of an exclusive > backup API, and it's not so easy to migrate their backup scripts so that > only non-exclusive one is used because of the reason I wrote in another thread. > https://postgr.es/m/CAHGQGwHUkEbkVexVfWNLjmq2rzOS_SHYMiECt+KBn-cBPq5Arg@mail.gmail.com Yeah, those are interesting points. Unfortunately, I think something as simple as your proposed... psql -c "SELECT pg_start_backup()" rsync, cp, tar, storage backup, or something psql -c "SELECT pg_stop_backup()" ...doesn't have much chance of being correct. If you aren't checking whether pg_start_backup() throws an error, for example, you have got a very failure-prone set-up. That being said, it's possible to fix that problem using some shell logic, whereas the problem of keeping a connection open for the duration of the backup from the shell is much harder. I recently ran across a case where someone attempted it but did not get the logic entirely right, with rather painful consequences. Now you might say that people should not write their own tools and just use professionally produced ones. But I don't really agree with that, and whatever we think people SHOULD do, there are in fact a lot of people using their own tools. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company