Re: Remove Deprecated Exclusive Backup Mode
Laurenz Albe <laurenz.albe@cybertec.at>
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>, Adrien NAYRAT
<adrien.nayrat@anayrat.info>, Robert Haas <robertmhaas@gmail.com>, David
Steele <david@pgmasters.net>, PostgreSQL Hackers
<pgsql-hackers@lists.postgresql.org>
Date: 2019-02-26T07:19:40Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Remove exclusive backup mode
- 39969e2a1e4d 15.0 landed
Fujii Masao wrote: > Another idea is to improve an exclusive backup method so that it will never > cause such issue. What about changing an exclusive backup mode of > pg_start_backup() so that it creates something like backup_label.pending file > instead of backup_label? Then if the database cluster has backup_label.pending > file but not recovery.signal (this is the case where the database is recovered > just after the server crashes while an exclusive backup is in progress), > in this idea, the recovery using that database cluster always ignores > (or removes) backup_label.pending file and start replaying WAL from > the REDO location that pg_control file indicates. So this idea enables us to > work around the issue that an exclusive backup could cause. Then if you restore a backup, but forget to add the recovery.signal file, PostgreSQL will happily recover from a wrong checkpoint and you end up with a corrupted database. I think the fundamental problem with all these approaches is that there is no safe way to distinguish a server crashed in backup mode from a restored backup. This is what makes the problem so hard. The existing exclusive backup is in my opinion the safest variant: it refuses to create a corrupted cluster without manual intervention and gives you a dire warning to consider if you are doing the right thing. Yours, Laurenz Albe