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

From Kyotaro Horiguchi
Subject Re: pg15b3: recovery fails with wal prefetch enabled
Date
Msg-id 20220901.141758.1654910865904256686.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: pg15b3: recovery fails with wal prefetch enabled  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: pg15b3: recovery fails with wal prefetch enabled
List pgsql-hackers
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:
> > On Thu, Sep 1, 2022 at 3:08 PM Kyotaro Horiguchi
> > <horikyota.ntt@gmail.com> wrote:
> > > Just for information, there was a fixed bug about
> > > overwrite-aborted-contrecord feature, which causes this kind of
> > > failure (xlog flush request exceeds insertion bleeding edge). If it is
> > > that, it has been fixed by 6672d79139 two-days ago.
> > 
> > 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.

> > If it's REL_15_BETA3, any chance you could cherry pick that change and
> > check what happens?  And without that, could you show what this logs
> > And without that, could you show what this logs
> > for good and bad recovery settings?
> 
> I wasn't sure what mean by "without that" , so here's a bunch of logs to
> sift through:

There's no need to cherry picking..

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Dmitry Markman
Date:
Subject: Re: question about access custom enum type from C
Next
From: Dmitry Markman
Date:
Subject: Re: question about access custom enum type from C