Re: corrupted tuple (header?), pg_filedump output - Mailing list pgsql-hackers

From Tom Lane
Subject Re: corrupted tuple (header?), pg_filedump output
Date
Msg-id 28792.1111104150@sss.pgh.pa.us
Whole thread Raw
In response to corrupted tuple (header?), pg_filedump output  (Eric Parusel <lists@globalrelay.net>)
Responses Re: corrupted tuple (header?), pg_filedump output  (Eric Parusel <lists@globalrelay.net>)
List pgsql-hackers
Eric Parusel <lists@globalrelay.net> writes:
> ./pg_filedump -i -f -R 28393 /data1/pgsql/data/base/17760/18004
> --snip--
>  Item   2 -- Length: 1728  Offset: 6464 (0x1940)  Flags: USED
>   XMIN: 12  CMIN: 196608  XMAX: 122552335  CMAX|XVAC: 177664675
>   Block Id: 0  linp Index: 47241   Attributes: 3692   Size: 0
>   infomask: 0x0900 (XMIN_COMMITTED|XMAX_INVALID)
>   Error: Computed header length not equal to header size.
>          Computed <28>  Header: <0>
> --snip--

None of those fields seem very sensible.  I suspect what's actually
corrupt is the ItemId in the page header --- ie, it's pointing at
something that's not a tuple header.  You might eyeball the ItemId
array and see if any pattern of corruption is visible.

(Oh btw: are you certain you have the right version of pg_filedump?
If it's older than your postmaster it might be giving you wrong
answers.)

> What do I do now?  Can this be repaired?
> This tuple is not needed, I can "get rid of it" or somehow dereference 
> it if need be.

If you can do without the whole page, the easiest way is to zero out the
entire page with 'dd'.  If you just want to kill that one tuple you can
reset the LP_USED bit in its ItemId.  Either way the postmaster needs to
be stopped to be sure that it's not got the page buffered while you
change it.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: caches lifetime with SQL vs PL/PGSQL procs
Next
From: Eric Parusel
Date:
Subject: Re: corrupted tuple (header?), pg_filedump output