On 2020-06-22 08:02:06 +0200, Paul Förster wrote:
> > On 22. Jun, 2020, at 07:36, Stephen Frost <sfrost@snowman.net> wrote:
> > 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.
Correct. Your backup will also almost certainly be missing some files,
so it won't be usable anyway.
> 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?
Restore the previous backup and replay WALs from there (that assumes of
course that you are archiving WALs continuously, but if you don't, you
can't do PITR in general, so if you have that requirement you are doing
it).
hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"