Обсуждение: invalid page header

INFO:  vacuuming "pg_toast.pg_toast_17242"
ERROR:  invalid page header in block 2003917 of relation "pg_toast_17242"

Is there a way to fix this error, or do I need to rebuild the table?

thanks
Michael.

Michael Guerin <guerin@rentec.com> writes:
> INFO:  vacuuming "pg_toast.pg_toast_17242"
> ERROR:  invalid page header in block 2003917 of relation "pg_toast_17242"

> Is there a way to fix this error, or do I need to rebuild the table?

zero_damaged_pages would get you past that error, but I'd be worrying
about what data you've lost or are going to lose.  Dumping and reloading
the table that owns this toast table would be a safer route; it would at
least make it real clear what damage you'd suffered.

            regards, tom lane

Michael Guerin <guerin@rentec.com> writes:
> "Dumping and reloading the table that owns this toast table would be a safer route; it would at
> least make it real clear what damage you'd suffered."

> Is this b/c the damaged pages would be zero'd out?

Right, which would make vacuum happy, but you'd be missing some data.
(Unless you're fortunate enough that there are no currently-live rows
on the damaged page.)

            regards, tom lane

"Dumping and reloading the table that owns this toast table would be a safer route; it would at
least make it real clear what damage you'd suffered."

Is this b/c the damaged pages would be zero'd out?   I tried searching the docs, but it seems the search daemon is
down.

Thanks
Michael



Tom Lane wrote:

>Michael Guerin <guerin@rentec.com> writes:
>
>
>>INFO:  vacuuming "pg_toast.pg_toast_17242"
>>ERROR:  invalid page header in block 2003917 of relation "pg_toast_17242"
>>
>>
>
>
>
>>Is there a way to fix this error, or do I need to rebuild the table?
>>
>>
>
>zero_damaged_pages would get you past that error, but I'd be worrying
>about what data you've lost or are going to lose.  Dumping and reloading
>the table that owns this toast table would be a safer route; it would at
>least make it real clear what damage you'd suffered.
>
>            regards, tom lane
>
>

Tom Lane wrote:

>Michael Guerin <guerin@rentec.com> writes:
>
>
>>"Dumping and reloading the table that owns this toast table would be a safer route; it would at
>>least make it real clear what damage you'd suffered."
>>
>>
>
>
>
>>Is this b/c the damaged pages would be zero'd out?
>>
>>
>
>Right, which would make vacuum happy, but you'd be missing some data.
>(Unless you're fortunate enough that there are no currently-live rows
>on the damaged page.)
>
>            regards, tom lane
>
>
I tried using pg_dump and copy, but both get errors and fail.  Is there
another way that I should try to export the data?  Also, I sent another
post recently trying to find out how these things happen.  The drives
seem to be ok, although I still need to memcheck.  This is the second
corruption in a 4 day span, but I can't find any clues to why its happening.

-michael

Michael Guerin <guerin@rentec.com> writes:
> Tom Lane wrote:
>>> "Dumping and reloading the table that owns this toast table would be a safer route; it would at
>>> least make it real clear what damage you'd suffered."

> I tried using pg_dump and copy, but both get errors and fail.  Is there
> another way that I should try to export the data?

That's about what I expected would happen.  What you're now down to is
having to identify and delete the specific rows that suffered damage.
Once you can do a "SELECT *" from the table without error, pg_dump will
work.

> Also, I sent another post recently trying to find out how these things
> happen.  The drives seem to be ok, although I still need to memcheck.
> This is the second corruption in a 4 day span, but I can't find any
> clues to why its happening.

I'd be pretty suspicious about bad RAM if I were you ...

            regards, tom lane