| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Kamigishi Rei <iijima(dot)yun(at)koumakan(dot)jp> |
| Cc: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Subject: | Re: BUG #17245: Index corruption involving deduplicated entries |
| Date: | 2021-10-29 20:49:45 |
| Message-ID: | 20211029204945.6hzta5dmxwtikurx@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2021-10-29 20:59:09 | Re: BUG #17245: Index corruption involving deduplicated entries |
| Previous Message | David G. Johnston | 2021-10-29 20:39:33 | Re: FW: BUG #17258: Unexpected results in CHAR(1) data type |