Nathan Robertson <nathan.robertson@xxxxxxxxx> writes:
> -bash-3.2$ postgres -O -P -D /tmp/database -c log_error_verbosity=verbose
> webapp
> FATAL: XX000: cache lookup failed for index 2662
> LOCATION: RelationInitIndexAccessInfo, relcache.c:841
Um ... and you said this was current 8.1.x ... so it's dying here:
tuple = SearchSysCache(INDEXRELID,
ObjectIdGetDatum(RelationGetRelid(relation)),
0, 0, 0);
if (!HeapTupleIsValid(tuple))
elog(ERROR, "cache lookup failed for index %u",
RelationGetRelid(relation));
I interpret this to mean that it can't find the pg_index row for
pg_class_oid_index --- and since you're using -P, that doesn't just mean
corruption in pg_index's indexes, but that the tuple can't be found even
by seqscanning the whole catalog. Probably the whole page it's in got
wiped out by your filesystem-level failure.
I hate to be the bearer of bad news, but I think this DB may be beyond
recovery. It's very unlikely that there's just the one tuple gone.
If you're willing to throw money at the problem, there are various
people who offer consulting services that include trying to reconstruct
broken Postgres databases; but you might be best advised to just take
your lumps and go back to your last good backup. At this point you're
looking at a significant investment of time with no guarantee of being
able to extract anything very useful.
What I'm taking from this is another horror story about the risks of
mounting databases across networks instead of locally :-(. Postgres
is only as reliable as the storage it's using.
regards, tom lane
--
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
