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

In the rare case of a crash of the source database while one or more databases are in progress.  Restoring the backup requires manual intervention with signal files today.

I get a desire for the live production server to not need intervention to recover from a crash but I can't help but feel that this requirement plus the goal of making this a non-interventionist as possible during recovery are incompatible.  But I haven't given it a great amount of thought as I felt the limited scope and situation were an acceptable cost for keeping the process straight-forward (i.e., starting up a backup mode instance requires a signal file that dictates the kind of recovery to perform).  We can either make the live backup contents invalid until something happens after pg_backup_stop ends that makes it valid or we have to make the current system being backed up invalid so long as it's in backup mode.  The later seemed easier and doesn't require actions outside of our control.