Hi Stephen, > On 22. Jun, 2020, at 07:36, Stephen Frost <sfrost@xxxxxxxxxxx> wrote: > That's not the only case that I, at least, have heard of- folks aren't > really very happy with their backups fail when they could have just as > well completed, even if they're overlapping. Sure, it's better if > backups are scheduled such that they don't overlap, but that can be hard > to guarantee. I see. > The thing about this is though that the new API avoids *other* issues, > like what happens if the system crashes during a backup (which is an > entirely common thing that happens, considering how long many backups > take...) and it does so in a relatively reasonable way while also > allowing concurrent backups, which is perhaps a relatively modest > benefit but isn't the main point of the different API. that makes me curious about another thing. The output of pg_stop_backup() is to be stored. Otherwise the backup is useless. So far, so good. But what if the server crashes in the middle of the backup and pg_stop_back() hence is never reached? In this case, it obviously does not create any output. Ok, you usually start the server, the database does a crash recovery and opens. Then, some time later, you do the usual backup and all is well. This is like 99.999% of all cases. But what if you need to restore to the latest transaction while the database was running in backup mode during which the crash occurred. How does that work if no pg_stop_backup() output exists? Did I miss something here? Cheers, Paul
