Re: pgsql: Fix handling of WAL segments ready to be archivedduring crash r

At Fri, 24 Apr 2020 10:14:37 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> On Fri, Apr 24, 2020 at 09:59:29AM +0900, Michael Paquier wrote:
> > And this visibly comes down to the fact that we don't take care enough
> > of the timing between the restartpoints done, the startup process
> > doing its recycling work and the archiver.  The rest of the test
> > relies on the reports of pg_stat_archiver a points to wait at as
> > published by the archiver process.  So there are two things we could
> > do here:
> > 1) Just remove the unstable parts of the tests (the three ones above),
> > and keep coverage based on everything we have using pg_stat_archiver.
> > 2) Remove the test entirely, though I would rather have us keep some
> > coverage, particularly for primaries as this got broken.
> > 
> > I'd rather do 2), any thoughts?
> 
> Oops, sorry.  I sent this message too quickly.  I would rather
> actually do 1) and keep the major parts of the tests.  All the
> buildfarm failures are just around the three checks mentioned
> upthread.

Thanks for your trouble fixing the failures. 

I think we can reimplement them by waiting
pg_stat_archiver.last_failed_wal at least for archive_mode=always
case. I'm not sure about the case where archive_mode=on, though.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center