On Sun, 2018-11-25 at 13:50 -0500, Stephen Frost wrote: > I don't see any compelling argument for trying to do something half-way > any more today than I did two years ago when this was being discussed.
That may well be so. It may be better to make users unhappy than to make them very unhappy... But I find the following points unconvincing: > > I would say the typical use case for the exclusive backup method is > > the following (and I have seen it often): > > > > You have some kind of backup software that does file system backups > > and is able to run a "pre-backup" and "post-backup" script. > > The backup is triggered by the backup software. > > Seeing it often doesn't make it a good solution. Running just > pre-backup and post-backup scripts and copying the filesystem isn't > enough to perform an online PostgreSQL backup- the WAL needs to be > collected as well, and you need to make sure that you have all of the > WAL before the backup can be considered complete. Yes, that's why "pg_stop_backup" has the "wait_for_archive" parameter. So this is not a problem. > On restore, you're > going to need to create a recovery.conf (at least in released versions) > which provides a restore command (needed even in HEAD today) to get the > old WAL, so having to also create the backup_label file shouldn't be > that difficult. You write "recovery.conf" upon recovery, when you have the restored backup, so you have it on a file system. No problem adding a file then. This is entirely different from adding a "backup_label" file to a backup that has been taken by a backup software in some arbitrary format in some arbitrary location (think snapshot). So these two cases don't compare. > Lastly, if you really want, you can extract out the data from > pg_stop_backup in whatever your post-backup script is. Come on, now. You usually use backup techniques like that because you can't get your large database backed up in the available time window otherwise. > > Another thing that is problematic with non-exclusive backups is that > > you have to write the backup_label file into the backup after the > > backup has been taken. With a technique like the above, you cannot > > easily do that. > > ... why not? You need to create the recovery.conf anyway, and you need > to be archiving WAL somewhere, so it certainly seems like you could put > the backup_label there too. As I said above, you don't add "recovery.conf" to the backup right away, so these two cases don't compare. > > I expect that that will make a lot of users unhappy. > > If it means that they implement a better backup strategy, then it's > probably a good thing, which is the goal of this. I thought our goal is to provide convenient backup methods... Ignoring "backup_label" on restart, as I suggested in my previous message, probably isn't such a hot idea. But what's wrong with retaining the exclusive backup method and just sticking a big "Warning: this may cause a restart to fail after a crash" on it? That sure wouldn't be unsafe. If somebody prefers a simpler backup method at the price of having to manually restart the server after a crash, what's wrong with that? Why not give them the choice? I'd say that one could write a server start script that just removes "backup_label", but I am sure someone will argue that then somebody will restore a backup and then restart the server without first recovering the database... Yours, Laurenz Albe
