Greetings,
* Fujii Masao (masao.fujii@gmail.com) wrote:
> On Wed, Feb 27, 2019 at 4:35 PM Laurenz Albe <laurenz.albe@cybertec.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.
There's a number of problems, imv, that I think have just been
ignored/missed when it comes to the recovery.conf removal and tools like
pg_basebackup, see this msg also:
https://postgr.es/m/20181127153405.GX3415@tamriel.snowman.net
At this point, I think we need to put these issues on the v12 open items
page so that we don't forget about them and get these things fixed
before v12 comes out.
Thanks!
Stephen