> What Postgres version are you using?
My apologies, should have included that with my original request:
[PostgreSQL 6.5.2 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66]
> If you want to try to recover without doing an update, I think you'll
> still need to do a pg_dump/destroydb/createdb/reload. It looks like
> the indexes on pg_attribute have been corrupted, and there's not any
> easier way to clean that up. (If it were a user table, you could just
> drop and recreate the index, but don't try that on pg_attribute...)
What are the ramifications of continuing with the corrupted indexes -
undefined behavior? Filesystems have fsck to fix stuff - are there any
tools on the docket to reconstruct the indexes or other recoverable
things? These would be useful for systems where the database is 500+ Megs
and takes quite awhile to reload.
The application involved uses temp files (you see some sort of attribute
failure in the VACUUM before everything goes haywire - perhaps unrelated)
as well as transactions. I don't create or drop temp tables inside
transactions to avoid the accompanying error messages. A database
maintenance program runs nightly to cull old data from the database and
then runs a vacuum. During that time, transactions continue unabated.
- K
Kristofer Munn * KMI * 973-509-9414 * AIM KrMunn * ICQ 352499 * www.munn.com
