On Apr 18, 2006, at 2:15 PM, Tom Lane wrote:
"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
I would've expected the RAID to protect postgres from the possibility
of data corruption, but I guess not.
Ooops :-(. It might be interesting to get pg_filedump dumps of the
corrupted pages, just to see what the failure pattern looks like.
I doubt there's much we can do about it, but you don't know till you
look. ("If we knew what it was we were doing, it wouldn't be
research.")
Any tips on turning "ERROR: invalid page header in block 34 of
relation" into a pg_filedump command that would yield something useful
or interesting? If so, I'll post the results of all three relations
known to be corrupt so far.
Also, are there any questions I could be asking vendors (Dell, LSI) that
would help sort out how the RAID contributed to corruption on disk?
--
Thomas F. O'Connell
Database Architecture and Programming
Sitening, LLC
http://www.sitening.com/
3004 B Poston Avenue
Nashville, TN 37203-1314
615-260-0005 (cell)
615-469-5150 (office)
615-469-5151 (fax)
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
