Re: [BUG] non archived WAL removed during production crash recovery

On Thu, 23 Apr 2020 14:05:46 +0900 (JST)
Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote:

> FWIW, the test for 10- looks fine, but I have one qustion.
>
> + 'archive success reported in pg_stat_archiver for WAL segment
> $segment_name_
>
> This seems intending to show an actual segment name in the message,
> but it is really shown as "... WAL segment $segment_name_1". Is that
> intended?

Good catch. Fixed in v11. Thank you.

> At Thu, 23 Apr 2020 08:46:18 +0900, Michael Paquier <michael(at)paquier(dot)xyz>
> wrote in
> > On Wed, Apr 22, 2020 at 06:17:17PM +0200, Jehan-Guillaume de Rorthais
> > wrote:
> > > I found an extra useless line of code in v9 patch. Please, find in
> > > attachment v10. Sorry for this.
> >
> > Thanks for helping here, your changes make sense. This looks mostly
> > fine to me except that part:
> > +$standby1->poll_query_until('postgres',
> > + qq{ SELECT pg_xlog_location_diff('$primary_lsn',
> > pg_last_xlog_replay_location()) = 0 })
> > + or die "Timed out while waiting for xlog replay";
> > Here we should check if $primary_lsn is at least
> > pg_last_xlog_replay_location(). Checking for an equality may stuck
> > the test if more WAL gets replayed. For example you could have a
> > concurrent autovacuum generating WAL.
>
> Autovacuum is turned off in this case, but anyway other kinds of WAL
> records can be generated.

make sense. Fixed in v11.

Please, find in v11 for version 9.5, 9.6 and 10.

Regards,