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.


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Michael Guerin <guerin (AT) rentec (DOT) com> writes:
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

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

"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:


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Michael Guerin <guerin (AT) rentec (DOT) com> writes:
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

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)

Tom Lane wrote:

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


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Michael Guerin <guerin (AT) rentec (DOT) com> writes:
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.

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

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html