Re: Improving Physical Backup/Restore within the Low Level API

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Improving Physical Backup/Restore within the Low Level API
Дата
Msg-id CAKFQuwYgHXAD9rpRNO6dR7-3HyV9f5t4wVgP=vZi-ovtmefm-g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Improving Physical Backup/Restore within the Low Level API  (David Steele <david@pgmasters.net>)
Список pgsql-hackers
Дерево обсуждения
On Tue, Oct 17, 2023 at 12:30 PM David Steele <david@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.johnston@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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Improve WALRead() to suck data directly from WAL buffers when possible
Следующее
От: Robert Haas
Дата:
Сообщение: Re: The danger of deleting backup_label