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
