Re: Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem? - Mailing list pgsql-hackers
From | Alvaro Herrera |
---|---|
Subject | Re: Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem? |
Date | |
Msg-id | 20140224205514.GU4759@eldon.alvh.no-ip.org Whole thread Raw |
In response to | Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem? (Greg Stark <stark@mit.edu>) |
Responses |
Re: Another possible corruption bug in 9.3.2 or possibly a
known MultiXact problem?
|
List | pgsql-hackers |
Here's a reformatted copy. I think this is the same bug as Peter G. reported in http://www.postgresql.org/message-id/CAM3SWZTMQiCi5PV5OWHb+bYkUcnCk=O67w0cSswPvV7XfUcU5g@mail.gmail.com I have a hunch that this is related to the heap_lock_updated business. I haven't investigated yet. Greg Stark wrote: > I have a database where a a couple rows don't appear in index scans > but do appear in sequential scans. It looks like the same problem as > Peter reported but this is a different database. I've extracted all > the xlogdump records and below are the ones I think are relevant. You > can see that lp 2 gets a few HOT updates and concurrently has someone > create a MultiXact NO KEY UPDATE lock while one of those HOT updates > is pending but not committed. The net result seems to be that the ctid > update chain got broken. The index of course points to the head of the > HOT chain so it doesn't find the live tail whereas the sequential scan > picks it up. > > I don't see any evidence of MultiXactId wraparound, the members run to > 001F and the offsets run to 000B. This is on a standby that's been > activated but afaik that shouldn't change these files any more right? > > rmgr: Heap len (rec/tot): 235/ 267, tx: 5943845, lsn: FD/2F0A3640, prev FD/2F0A3600, bkp: 0000, desc: insert:rel 1663/16385/212653; tid 13065/2 > rmgr: Transaction len (rec/tot): 12/ 44, tx: 5943845, lsn: FD/2F0A8178, prev FD/2F0A8148, bkp: 0000, desc: commit:2014-02-19 20:41:23.698513 UTC > rmgr: Heap len (rec/tot): 25/ 57, tx: 5943847, lsn: FD/2F0AA440, prev FD/2F0AA3F8, bkp: 0000, desc: lock5943847: rel 1663/16385/212653; tid 13065/2 LOCK_ONLY KEYSHR_LOCK > rmgr: Transaction len (rec/tot): 12/ 44, tx: 5943847, lsn: FD/2F0AA480, prev FD/2F0AA440, bkp: 0000, desc: commit:2014-02-19 20:41:23.713969 UTC > rmgr: Heap len (rec/tot): 291/ 323, tx: 5943849, lsn: FD/2F0ADFC0, prev FD/2F0ADF90, bkp: 0000, desc: hot_update:rel 1663/16385/212653; tid 13065/2 xmax 5943849 ; new tid 13065/3 xmax 0 > rmgr: Heap2 len (rec/tot): 25/ 57, tx: 5943851, lsn: FD/2F0AE450, prev FD/2F0AE408, bkp: 0000, desc: lockupdated: xmax 5943851 msk 000a; rel 1663/16385/212653; tid 13065/3 > rmgr: MultiXact len (rec/tot): 28/ 60, tx: 5943851, lsn: FD/2F0AE490, prev FD/2F0AE450, bkp: 0000, desc: createmxid 728896 offset 1632045 nmembers 2: 5943849 (nokeyupd) 5943851 (keysh) > rmgr: Heap len (rec/tot): 25/ 57, tx: 5943851, lsn: FD/2F0AE4D0, prev FD/2F0AE490, bkp: 0000, desc: lock728896: rel 1663/16385/212653; tid 13065/2 IS_MULTI EXCL_LOCK > rmgr: Transaction len (rec/tot): 12/ 44, tx: 5943849, lsn: FD/2F0AE510, prev FD/2F0AE4D0, bkp: 0000, desc: commit:2014-02-19 20:41:23.744989 UTC > rmgr: Transaction len (rec/tot): 12/ 44, tx: 5943851, lsn: FD/2F0AE570, prev FD/2F0AE540, bkp: 0000, desc: commit:2014-02-19 20:41:23.746820 UTC > rmgr: Heap len (rec/tot): 306/ 338, tx: 5943879, lsn: FD/2F103788, prev FD/2F103758, bkp: 0000, desc: hot_update:rel 1663/16385/212653; tid 13065/3 xmax 5943879 ; new tid 13065/4 xmax 0 > rmgr: Transaction len (rec/tot): 12/ 44, tx: 5943879, lsn: FD/2F1038E0, prev FD/2F103788, bkp: 0000, desc: commit:2014-02-19 20:41:24.580827 UTC > rmgr: Heap len (rec/tot): 306/ 338, tx: 5943880, lsn: FD/2F103910, prev FD/2F1038E0, bkp: 0000, desc: hot_update:rel 1663/16385/212653; tid 13065/4 xmax 5943880 ; new tid 13065/7 xmax 0 > rmgr: Transaction len (rec/tot): 12/ 44, tx: 5943880, lsn: FD/2F106070, prev FD/2F106030, bkp: 0000, desc: commit:2014-02-19 20:41:24.617048 UTC > > > lp | lp_off | lp_flags | lp_len | t_xmin | t_xmax | t_field3 | t_ctid | t_infomask2 | t_infomask | t_hoff | > ----+--------+----------+--------+---------+---------+----------+------------+-------------+------------+--------+- > 2 | 3424 | 1 | 232 | 5943845 | 728896 | 0 | (13065,2) | 32 | 4419 | 32 | > 3 | 3152 | 1 | 272 | 5943849 | 5943879 | 0 | (13065,4) | 49184 | 9475 | 32 | > 4 | 2864 | 1 | 287 | 5943879 | 5943880 | 0 | (13065,7) | 49184 | 9475 | 32 | > 7 | 2576 | 1 | 287 | 5943880 | 0 | 0 | (13065,7) | 32800 | 10499 | 32 | > > > -- > greg > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
pgsql-hackers by date: