From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | David Steele <david(at)pgmasters(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net>, Adrien NAYRAT <adrien(dot)nayrat(at)anayrat(dot)info>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Remove Deprecated Exclusive Backup Mode |
Date: | 2019-02-28 14:44:06 |
Message-ID: | CAHGQGwHgF15OUB-gN+xtHRTp2=8r0Z+ZwARqE51-Ts3ywXcUuA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Feb 27, 2019 at 4:35 PM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
>
> Fujii Masao wrote:
> > So, let me clarify the situations;
> >
> > (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
>
> That's where I see the problem with your idea.
>
> It is fairly easy for someone to restore a backup and then just start
> the server without first creating "recovery.signal", and that would
> lead to data corruption.
Isn't this case problematic even when a backup was taken by pg_basebackup?
Because of lack of recovery.signal, no archived WAL files are replayed and
the database may not reach to the latest point.
Regards,
--
Fujii Masao
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2019-02-28 14:45:22 | Re: Row Level Security − leakproof-ness and performance implications |
Previous Message | Alexander Kuzmenkov | 2019-02-28 14:27:51 | Re: Optimze usage of immutable functions as relation |