Re: BUG #17245: Index corruption involving deduplicated entries

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: BUG #17245: Index corruption involving deduplicated entries
Дата
Msg-id 20211029204945.6hzta5dmxwtikurx@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: BUG #17245: Index corruption involving deduplicated entries  (Kamigishi Rei <iijima.yun@koumakan.jp>)
Ответы 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,

There's something odd going on with 540,41, see below.


On 2021-10-29 22:52:39 +0300, Kamigishi Rei wrote:
> rmgr: Heap        len (rec/tot):     98/    98, tx:    2013796, lsn:
> 2/8DAAA0A0, prev 2/8DAA8548, desc: UPDATE off 5 xmax 2013796 flags 0x61
> KEYS_UPDATED ; new off 22 xmax 2013796, blkref #0: rel 1663/19243/19560 blk
> 540

Does a non-HOT update, from 540,5 to 540,22


> rmgr: Heap2       len (rec/tot):     56/    56, tx:          0, lsn:
> 2/8DABF558, prev 2/8DABF528, desc: PRUNE latestRemovedXid 2013796
> nredirected 0 ndead 1, blkref #0: rel 1663/19243/19560 blk 540

This presumably marks 540,5 dead, given that the removed xid is the same.


> rmgr: Heap        len (rec/tot):     83/    83, tx:    2013798, lsn:
> 2/8DABF5C8, prev 2/8DABF590, desc: HOT_UPDATE off 22 xmax 2013798 flags 0x60
> ; new off 41 xmax 2013798, blkref #0: rel 1663/19243/19560 blk 540

HOT of 540,22 (which was 540,5), now at 540,41.


> rmgr: Heap2       len (rec/tot):     58/    58, tx:          0, lsn:
> 2/8DACCBB0, prev 2/8DACCB88, desc: PRUNE latestRemovedXid 2013798
> nredirected 1 ndead 0, blkref #0: rel 1663/19243/19560 blk 540

Presumably redirecting 540,22 -> 540->41,


> rmgr: Heap        len (rec/tot):     99/    99, tx:    2014289, lsn:
> 2/8DEB5250, prev 2/8DEB36D8, desc: UPDATE off 41 xmax 2014289 flags 0x60
> KEYS_UPDATED ; new off 53 xmax 2014289, blkref #0: rel 1663/19243/19560 blk
> 540

Non-HOT of 540,41 (which was 540,22, 540,5), now at 540,53.


> rmgr: Heap2       len (rec/tot):     58/    58, tx:          0, lsn:
> 2/8DEC0420, prev 2/8DEC03F0, desc: PRUNE latestRemovedXid 2014289
> nredirected 0 ndead 1, blkref #0: rel 1663/19243/19560 blk 540

Likely marks 540,41 dead


> 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?


> rmgr: Heap2       len (rec/tot):     58/    58, tx:          0, lsn:
> 2/8DED6A10, prev 2/8DED69E8, desc: PRUNE latestRemovedXid 2014291
> nredirected 1 ndead 0, blkref #0: rel 1663/19243/19560 blk 540

Likely redirecting 540,53 -> 540,41


> rmgr: Heap        len (rec/tot):     59/  7939, tx:    2014784, lsn:
> 2/8DFB15D0, prev 2/8DFB1598, desc: LOCK off 41: xid 2014784: flags 0x00
> LOCK_ONLY EXCL_LOCK KEYS_UPDATED , blkref #0: rel 1663/19243/19560 blk 540
> FPW
> rmgr: Heap        len (rec/tot):    100/   100, tx:    2014784, lsn:
> 2/8DFDAD20, prev 2/8DFD9180, desc: UPDATE off 41 xmax 2014784 flags 0x60
> KEYS_UPDATED ; new off 57 xmax 2014784, blkref #0: rel 1663/19243/19560 blk
> 540
> rmgr: Heap2       len (rec/tot):     58/    58, tx:          0, lsn:
> 2/8DFE5F90, prev 2/8DFE5F60, desc: PRUNE latestRemovedXid 2014784
> nredirected 0 ndead 1, blkref #0: rel 1663/19243/19560 blk 540
> rmgr: Heap        len (rec/tot):     54/    54, tx:    2014786, lsn:
> 2/8DFE5FD0, prev 2/8DFE5F90, desc: LOCK off 57: xid 2014786: flags 0x00
> LOCK_ONLY EXCL_LOCK , blkref #0: rel 1663/19243/19560 blk 540
> rmgr: Heap        len (rec/tot):     82/    82, tx:    2014786, lsn:
> 2/8DFE6020, prev 2/8DFE5FD0, desc: HOT_UPDATE off 57 xmax 2014786 flags 0x60
> ; new off 41 xmax 2014786, blkref #0: rel 1663/19243/19560 blk 540

Same deal. I don't understand why this is possible?


> rmgr: Heap        len (rec/tot):     59/  8115, tx:    2085600, lsn:
> 2/A0165A70, prev 2/A0165A38, desc: LOCK off 22: xid 2085600: flags 0x00
> LOCK_ONLY EXCL_LOCK KEYS_UPDATED , blkref #0: rel 1663/19243/19560 blk 540
> FPW
> rmgr: Heap        len (rec/tot):     54/    54, tx:    2085600, lsn:
> 2/A018E858, prev 2/A018D7D8, desc: LOCK off 22: xid 2085600: flags 0x00
> LOCK_ONLY EXCL_LOCK KEYS_UPDATED , blkref #0: rel 1663/19243/19560 blk 540
> rmgr: Heap        len (rec/tot):     73/  8237, tx:    2085600, lsn:
> 2/A018E890, prev 2/A018E858, desc: UPDATE off 22 xmax 2085600 flags 0x03
> KEYS_UPDATED ; new off 21 xmax 2085600, blkref #0: rel 1663/19243/19560 blk
> 328 FPW, blkref #1: rel 1663/19243/19560 blk 540

This is also odd. Why are we locking the same row twice, in the same
transaction?

Greetings,

Andres Freund



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

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