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 CAKFQuwZ=-j0xVDrfCg7LEoHsRWWT1HaOHSckyXf8KA0-g2xOYQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Improving Physical Backup/Restore within the Low Level API  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: Improving Physical Backup/Restore within the Low Level API  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, Oct 16, 2023 at 12:36 PM David G. Johnston <david.g.johnston@gmail.com> wrote:
On Mon, Oct 16, 2023 at 12:09 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
I think it won't meet with favor if there are cases that require manual intervention
for starting the server.  That was the main argument for getting rid of the exclusive
backup API, which had a similar problem.

In the rare case of a crash of the source database while one or more databases are in progress.

Or even more simply, just document that should the process executing pg_backup_start, and eventually pg_backup_end, that noticed its session die out from under it, should just add crash.signal to the data directory (there probably can be a bit more intelligence involved in case the session crash was isolated).  A normal server shutdown should remove any crash.signal files it sees (and ensure in_backup="false"...).  A non-normal shutdown is going to end up in crash recovery anyway so having the signal file there won't harm anything even if pg_control is showing "in_backup=false".

In short, I probably don't know the details well enough to code the solution but this seems solvable for those users that need automatic reboot and crash recovery during an incomplete backup.  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.  It specifically requires creation of crash.signal, the specific method being unimportant and its contents being fixed - whether empty or otherwise.

David J.

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [PATCH] Clarify the behavior of the system when approaching XID wraparound
Следующее
От: Timothy Nelson
Дата:
Сообщение: Re: Postgres Architecture