Re: Remove Deprecated Exclusive Backup Mode
Fujii Masao <masao.fujii@gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: David Steele <david@pgmasters.net>,
Laurenz Albe <laurenz.albe@cybertec.at>, Stephen Frost <sfrost@snowman.net>,
Adrien NAYRAT <adrien.nayrat@anayrat.info>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-02-26T17:32:12Z
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
On Wed, Feb 27, 2019 at 2:27 AM Robert Haas <robertmhaas@gmail.com> wrote: > > On Tue, Feb 26, 2019 at 12:20 PM Fujii Masao <masao.fujii@gmail.com> wrote: > > So, let me clarify the situations; > > > > (1) If backup_label and recovery.signal exist, the recovery starts safely. > > This is the normal case of recovery from the base backup. > > > > (2)If backup_label.pending and recovery.signal exist, as described above, > > PANIC error happens at the start of recovery. This case can happen > > if the operator forgets to rename backup_label.pending, i.e., > > operation mistake. So, after PANIC, the operator needs to fix her or > > his mistake (i.e., rename backup_label.pending) and restart > > the recovery. > > > > (3) If backup_label.pending exists but recovery.signal doesn't, the server > > ignores (or removes) backup_label.pending and do the recovery > > starting the pg_control's REDO location. This case can happen if > > the server crashes while an exclusive backup is in progress. > > So crash-in-the-middle-of-backup doesn't prevent the recovery from > > starting in this idea. > > The if-conditions for 1 and 2 appear to be the same, which is confusing. Using other name like backup_in_progress instead of backup_label.pending may help a bit for your concern? That is, (1) backup_label and recovery.signal (2) backup_in_progress and recovery.signal Regards, -- Fujii Masao