Re: Improving Physical Backup/Restore within the Low Level API - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Improving Physical Backup/Restore within the Low Level API
Date
Msg-id CAKFQuwZ=-j0xVDrfCg7LEoHsRWWT1HaOHSckyXf8KA0-g2xOYQ@mail.gmail.com
Whole thread Raw
In response to Re: Improving Physical Backup/Restore within the Low Level API  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: Improving Physical Backup/Restore within the Low Level API
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PATCH] Clarify the behavior of the system when approaching XID wraparound
Next
From: Timothy Nelson
Date:
Subject: Re: Postgres Architecture