RE: Stronger safeguard for archive recovery not to miss data

On Monday, April 5, 2021 11:49 PM osumi(dot)takamichi(at)fujitsu(dot)com <osumi(dot)takamichi(at)fujitsu(dot)com>
> On Mon Apr 5, 2021 12:35 PM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
> wrote:
> > >>> By the way, when I build postgres with this patch and
> > >>> enable-coverage option, the results of RT becomes unstable. Does
> > >>> someone know the
> > >> reason ?
> > >>> When it fails, I get stderr like below
> > >>
> > >> I have no idea about this. Does this happen even without the patch?
> > > Unfortunately, no. I get this only with --enable-coverage and with
> > > my patch, althought regression tests have passed with this patch.
> > > OSS HEAD doesn't produce the stderr even with --enable-coverage.
> >
> > Could you check whether the latest patch still causes this issue or not?
> > If it still causes, could you check which part (the change of xlog.c
> > or the addition of regression test) caused the issue?
> v07 reproduces the phenomena, even with make coverage-clean between
> tests.
> The possibility is not high though.
>
> We cannot do the regression test separately from xlog.c because it uses the
> new error message of xlog.c.
> Applying only the TAP test should fail because we get an warning not error.
>
> Therefore, I took the changes of xlog.c only and I'm doing the RT in a loop
> now. If we can get the stderr again, then we can guess xlog.c is the cause,
> right ?
>
> I think I can report the result tomorrow.
> Just in case, I'm running the RT for OSS HEAD in parallel...
> although I cannot reproduce it with it at all.
I really apologie that this OSS HEAD reproduced that stderr with success of RT.
I executed check-world in parallel with -j option so
the reason should be what Tsunakawa-san told us.
Its probability is pretty low.
I'm so sorry for making noises loudly.
Therefore, I don't have any concern left.

Best Regards,
Takamichi Osumi