On 11/26/18 12:31 AM, Laurenz Albe wrote:
On Sun, 2018-11-25 at 16:04 -0500, Stephen Frost wrote:
There isn’t any need to write the backup label before you restore the database,
just as you write recovery.conf then.
Granted.
But it is pretty convenient, and writing it to the data directory right away
is a good thing on top, because it reduces the danger of inadvertedly
starting the backup without recovery.
Writing it into the data directory is *not* a good thing because as soon as you
do
that you risk there being an issue if there’s a crash. Writing into the backup
isn’t a bad idea but if you’re managing your backups then writing it somewhere
else
(such as where you write your WAL) and associating it with the backup
(presumably
it has a label) should make it easy to pull back when you restore.
If there is a crash during the backup procedure, the backup is bad.
Doesn't matter during which part of the backup procedure it happens.
Yes, but in this case with exclusive backups your cluster also will not
start. That's a lot different than a bad backup because you should have
many backups and a way to mark when they are complete. If your cluster
requires manual intervention to start because a backup was in progress
that's not a good thing.
I'm of the opinion that we should remove the exclusive option for PG12.
The recovery changes recently committed will completely break any
automated recovery written for PG <= 11 so we might as go all the way.
Requiring non-exclusive backup will be an easy change for tools that
already understand non-exclusive backup, which has been available in the
last three versions of Postgres.
The exclusive backup method tries to make a hard problem look simple but
does not succeed and causes issues besides. Performing backups properly
*is* hard and we don't do anyone a service by making it look like
something can be done with a trivial bash script.
Regards,
--
-David
da...@pgmasters.net
