Re: BUG #17245: Index corruption involving deduplicated entries

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: BUG #17245: Index corruption involving deduplicated entries
Дата
Msg-id 20211029205909.ycbqxtz75srf75lu@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: BUG #17245: Index corruption involving deduplicated entries  (Andres Freund <andres@anarazel.de>)
Ответы Re: BUG #17245: Index corruption involving deduplicated entries  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-bugs
Hi,

On 2021-10-29 13:49:45 -0700, Andres Freund wrote:
> > rmgr: Heap        len (rec/tot):     54/    54, tx:    2014291, lsn:
> > 2/8DEC0460, prev 2/8DEC0420, desc: LOCK off 53: xid 2014291: flags 0x00
> > LOCK_ONLY EXCL_LOCK , blkref #0: rel 1663/19243/19560 blk 540
> > rmgr: Heap        len (rec/tot):     82/    82, tx:    2014291, lsn:
> > 2/8DEC0498, prev 2/8DEC0460, desc: HOT_UPDATE off 53 xmax 2014291 flags 0x60
> > ; new off 41 xmax 2014291, blkref #0: rel 1663/19243/19560 blk 540
> 
> HOT of 540,53, now at 540,41.
> 
> Here I am confused. 540,41 was presumably marked dead in 2/8DEC0420, but not
> marked unused? So this shouldn't be possible.
> 
> What am I missing?

Oh. Likely the issue is that heap2_desc() doesn't print the number of
redirects.

I'm considering writing a patch that
1) displays the number of tuples marked unused in HEAP2_PRUNE. This might only
   be possible if no FPW was used
2) if a HEAP2_PRUNE or HEAP2_VACUUM isn't an FPW, display the offsets


For 15 I think it might be worth to explicitly store the number of offets
marked unused, rather than inferring that. It's hard to believe that the 16
bit for that would be a relevant overhead, and having that more readily
available seems like a significant improvement in debuggability.

Greetings,

Andres Freund



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: BUG #17245: Index corruption involving deduplicated entries
Следующее
От: "David M. Calascibetta"
Дата:
Сообщение: RE: FW: BUG #17258: Unexpected results in CHAR(1) data type