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

On Mon, Oct 16, 2023 at 12:36 PM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> On Mon, Oct 16, 2023 at 12:09 PM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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.