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.120804.504461198570722498.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: pg15b3: recovery fails with wal prefetch enabled  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: pg15b3: recovery fails with wal prefetch enabled
List pgsql-hackers
At Thu, 1 Sep 2022 12:05:36 +1200, Thomas Munro <thomas.munro@gmail.com> wrote in 
> On Thu, Sep 1, 2022 at 2:01 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
> > < 2022-08-31 08:44:10.495 CDT  >LOG:  checkpoint starting: end-of-recovery immediate wait
> > < 2022-08-31 08:44:10.609 CDT  >LOG:  request to flush past end of generated WAL; request 1201/1CAF84F0, current
position1201/1CADB730
 
> > < 2022-08-31 08:44:10.609 CDT  >CONTEXT:  writing block 0 of relation base/16881/2840_vm
> > < 2022-08-31 08:44:10.609 CDT  >ERROR:  xlog flush request 1201/1CAF84F0 is not satisfied --- flushed only to
1201/1CADB730
> > < 2022-08-31 08:44:10.609 CDT  >CONTEXT:  writing block 0 of relation base/16881/2840_vm
> > < 2022-08-31 08:44:10.609 CDT  >FATAL:  checkpoint request failed
> >
> > I was able to start it with -c recovery_prefetch=no, so it seems like
> > prefetch tried to do too much.  The VM runs centos7 under qemu.
> > I'm making a copy of the data dir in cases it's needed.

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.

http://postgr.es/m/CAFiTN-t7umki=PK8dT1tcPV=mOUe2vNhHML6b3T7W7qqvvajjg@mail.gmail.com
http://postgr.es/m/FB0DEA0B-E14E-43A0-811F-C1AE93D00FF3%40amazon.com

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Instrumented pages/tuples frozen in autovacuum's server log out (and VACUUM VERBOSE)
Next
From: David Rowley
Date:
Subject: Re: Reducing the chunk header sizes on all memory context types