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

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: molofeev <molofeev3(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15142: ERROR: MultiXactId nnnnn has not been created yet -- apparent wraparound in v9.5
Date: 2018-04-04 16:14:26
Message-ID: 87woxnj75g.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

>>>>> "Alvaro" == Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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)

In response to

Responses

Browse pgsql-bugs by date

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