Re: corrupted tuple (header?), pg_filedump output

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Eric Parusel <lists(at)globalrelay(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: corrupted tuple (header?), pg_filedump output
Date: 2005-03-18 00:02:30
Message-ID: 28792.1111104150@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Eric Parusel <lists(at)globalrelay(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Eric Parusel 2005-03-18 00:21:23 Re: corrupted tuple (header?), pg_filedump output
Previous Message Tom Lane 2005-03-17 23:51:24 Re: Excessive growth of pg_attribute and other system tables