On Mon, 2023-10-16 at 11:18 -0700, David G. Johnston wrote:
> > I see a couple of problems and/or things that need clarification with that idea:
> >
> > - Two backups can run concurrently. How do you reconcile that with the "in backup"
> > flag and crash.signal?
> > - I guess crash.signal is created during pg_start_backup(). So that file will be
> > included in the backup. How do you handle that during recovery? Ignore it if
> > another signal file is present? And if the user forgets to create a signal file
> > for recovery, how do you prevent PostgreSQL from performing crash recovery?
> >
>
> crash.signal is created in the pg_backup_metadata directory, not the root directory.
> Should the server crash while any backup is in progress pg_control would be aware
> of that fact (in_backup=true would still be there, instead of in_backup=false which
> only comes back after all backups have completed) and the server will not restart
> without user intervention - specifically, moving the crash.signal file from (one of)
> the pg_backup_metadata subdirectories to the root directory. As there is nothing
> special about the crash.signal files in the pg_backup_metadata subdirectories
> "touch crash.signal" could be used.
I see - I missed the part with the pg_backup_metadata directory.
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.
Also, how do you envision two concurrent backups with your setup?
Yours,
Laurenz Albe
