Re: pg15b3: recovery fails with wal prefetch enabled - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: pg15b3: recovery fails with wal prefetch enabled
Date
Msg-id CA+hUKGK6C=4spoW3iSmU4HbhXu0Qghbn-r7fiCb3C2Lh9HugMA@mail.gmail.com
Whole thread Raw
In response to Re: pg15b3: recovery fails with wal prefetch enabled  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: pg15b3: recovery fails with wal prefetch enabled
List pgsql-hackers
On Thu, Sep 1, 2022 at 5:18 PM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
> At Wed, 31 Aug 2022 23:47:53 -0500, Justin Pryzby <pryzby@telsasoft.com> wrote in
> > On Thu, Sep 01, 2022 at 04:22:20PM +1200, Thomas Munro wrote:
> > > Hmm.  Justin, when you built from source, which commit were you at?
> > > If it's REL_15_BETA3,
> >
> > No - it's:
> > commit a2039b1f8e90d26a7e2a115ad5784476bd6deaa2 (HEAD -> REL_15_STABLE, origin/REL_15_STABLE)
>
> It's newer than eb29fa3889 (6672d79139 on master) so it is fixed at
> that commit.

Yeah.

> > I wasn't sure what mean by "without that" , so here's a bunch of logs to
> > sift through:

So it *looks* like it finished early (and without the expected
error?).  But it also looks like it replayed that record, according to
the page LSN.  So which is it?  Could you recompile with WAL_DEBUG
defined in pg_config_manual.h, and run recovery with wal_debug = on,
and see if it replays 1CAF84B0?



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: FOR EACH ROW triggers, on partitioend tables, with indexes?
Next
From: Justin Pryzby
Date:
Subject: Re: pg15b3: recovery fails with wal prefetch enabled