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