On Tue, Oct 17, 2023 at 12:30 PM David Steele <da...@pgmasters.net> wrote:
> On 10/17/23 14:28, Robert Haas wrote: > > On Mon, Oct 16, 2023 at 5:21 PM David G. Johnston > > <david.g.johns...@gmail.com> wrote: > >> But no, by default, and probably so far as pg_basebackup is concerned, > a server crash during backup results in requiring outside intervention in > order to get the server to restart. > > > > Others may differ, but I think such a proposal is dead on arrival. As > > Laurenz says, that's just reinventing one of the main problems with > > exclusive backup mode. > > I concur -- this proposal resurrects the issues we had with exclusive > backups without solving the issues being debated elsewhere, e.g. torn > reads of pg_control or users removing backup_label when they should not. > > Thank you all for the feedback. Admittedly I don't understand the problem of torn reads well enough to solve it here but I figured by moving the "must not remove" stuff out of backup_label and into pg_control the odds of it being removed from the backup and the backup still booting basically go to zero. I do agree that renaming backup_label to something like "recovery_stuff_do_not_delete.conf" probably does that just as well without the downside. Placing a copy of all relevant files into pg_backup_metadata seems like a decent shield against accidents and a way to reliably self-document the backup even if the behavioral changes are not desired. Though doing that and handling multiple concurrent backups probably makes the cost too high to move away from relying just on documentation. I suppose I'd consider having to add one file to the data directory to be an improvement over having to remove two of them - in terms of what it takes to recover from system failure during a backup. David J
