Re: corrupted tuple (header?), pg_filedump output

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: corrupted tuple (header?), pg_filedump output
Дата
Msg-id 28792.1111104150@sss.pgh.pa.us
обсуждение исходный текст
Ответ на corrupted tuple (header?), pg_filedump output  (Eric Parusel <lists@globalrelay.net>)
Ответы Re: corrupted tuple (header?), pg_filedump output
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: caches lifetime with SQL vs PL/PGSQL procs
Следующее
От: Eric Parusel
Дата:
Сообщение: Re: corrupted tuple (header?), pg_filedump output