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