Re: BUG #17245: Index corruption involving deduplicated entries - Mailing list pgsql-bugs

From Andres Freund
Subject Re: BUG #17245: Index corruption involving deduplicated entries
Date
Msg-id 20211029213048.q5ltta6dze3sykh3@alap3.anarazel.de
Whole thread Raw
In response to Re: BUG #17245: Index corruption involving deduplicated entries  (Kamigishi Rei <iijima.yun@koumakan.jp>)
Responses Re: BUG #17245: Index corruption involving deduplicated entries  (Andres Freund <andres@anarazel.de>)
List pgsql-bugs
Hi,

On 2021-10-30 00:08:25 +0300, Kamigishi Rei wrote:
> On 29.10.2021 23:18, Andres Freund wrote:
> > Could you search for btree WAL records before the following records? Most
> > importantly for the corrupted page in the corrupted index, but other ones
> > might be interesting as well
> > 
> > > rmgr: Heap2       len (rec/tot):     53/  7937, tx:          0, lsn:
> > > 2/90CEF528, prev 2/90CEF4E8, desc: VACUUM nunused 3, blkref #0: rel
> > > 1663/19243/19560 blk 540 FPW
> > > rmgr: Heap2       len (rec/tot):     53/  8109, tx:          0, lsn:
> > > 2/97ED2598, prev 2/97ED2558, desc: VACUUM nunused 1, blkref #0: rel
> > > 1663/19243/19560 blk 540 FPW
> 
> These are daily vacuum runs (on the 27th and on the 28th) with dozens of
> preceding VACUUM lines for other tables. Should I try to filter out those?

I think it's moot for now, because of the discovery that waldump for PRUNE
doesn't show records marked unused. I'll try to write a patch to change that.

After that it'd mostly be interesting to see just enough records for btree
vacuums not affecting the target table to establish which indexes were
vacuumed. I.e. only records back until a heap VACUUM for a different table
started, and only a single record for each other index. Does that make sense?

Greetings,

Andres Freund



pgsql-bugs by date:

Previous
From: "David M. Calascibetta"
Date:
Subject: RE: BUG #17258: Unexpected results in CHAR(1) data type
Next
From: Mark Dilger
Date:
Subject: Re: BUG #17258: Unexpected results in CHAR(1) data type