Re: Remove Deprecated Exclusive Backup Mode
Adrien Nayrat <adrien.nayrat@anayrat.info>
From: Adrien NAYRAT <adrien.nayrat@anayrat.info>
To: Robert Haas <robertmhaas@gmail.com>, Fujii Masao <masao.fujii@gmail.com>
Cc: David Steele <david@pgmasters.net>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-02-25T09:28:28Z
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 2/22/19 7:10 PM, Robert Haas wrote: > 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. > FWIW +1 for not remove exclusive backup. Maintain a connection during the backup is a hard pre-requisite. In my previous jobs I already done custom scripts to perform backup by using pre/post backup hook to control backup software: With vmware to do PITR backup with VM snapshot or with another file backup tool which perform block deduplication. I do not see where is the problem if you check pg_start_backup()/pg_stop_backup() went well? It will be annoying if after this removal, companies must change their backup strategy by using specific postgres tools (pgbackrest, barman). Regards,