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

Andrew Gierth wrote:
> >>>>> "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).

Ah.

> 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.

/me scratches head

> 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.

I guess that'd also explain why there are so many tuples -- beyond the
maximum for heap pages.

> The multixact error occurs because pg is reading garbage from the xid
> and infomask fields since those don't exist in index tuples.

Ouch. I had never seen this. Maybe the OP can ship the page image?
May contain private data, though.

Maybe try to read with with bt_page_items() and/or other index methods
to confirm the theory?

I would guess that this is some sort of storage error -- a SAN or RAID
controller that malfunctions, or something like that. This I've seen.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services