Re: BUG #15142: ERROR: MultiXactId nnnnn has not been created yet -- apparent wraparound in v9.5 - Mailing list pgsql-bugs

From Andrew Gierth
Subject Re: BUG #15142: ERROR: MultiXactId nnnnn has not been created yet -- apparent wraparound in v9.5
Date
Msg-id 87woxnj75g.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: BUG #15142: ERROR: MultiXactId nnnnn has not been created yet --apparent wraparound in v9.5  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: BUG #15142: ERROR: MultiXactId nnnnn has not been created yet --apparent wraparound in v9.5  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Re: BUG #15142: ERROR: MultiXactId nnnnn has not been created yet -- apparent wraparound in v9.5  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-bugs
>>>>> "Alvaro" == Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

 >> Query 1:  select * from heap_page_items(get_raw_page('tablename',3220145));

 Alvaro> In this one, t_infomask is 11011 for all the tuples, which is
 Alvaro> 0x2B03. HEAP_XMAX_IS_MULTI is 0x1000. I think you're looking at
 Alvaro> the wrong pages, probably because of synchronized_seqscans.

3220145 appears to be a valid page (it's the one with the last
selectable row in the last slot). It's 3220146 which looks corrupt, but
it's corrupt in such a way that heap_page_items doesn't report anything
interesting because all the lp_len fields are 16.

My working hypothesis is that page 3220146 has actually been overwritten
by a page from some index, which is why it looks like valid (but too
short) items. The multixact error occurs because pg is reading garbage
from the xid and infomask fields since those don't exist in index
tuples.

--
Andrew (irc:RhodiumToad)


pgsql-bugs by date:

Previous
From: Александр Молофеев
Date:
Subject: Re: BUG #15142: ERROR: MultiXactId nnnnn has not been created yet --apparent wraparound in v9.5
Next
From: Alvaro Herrera
Date:
Subject: Re: BUG #15142: ERROR: MultiXactId nnnnn has not been created yet --apparent wraparound in v9.5