Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id A1F376327DB for ; Wed, 30 Jun 2010 17:59:34 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 63712-02 for ; Wed, 30 Jun 2010 20:59:26 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 23EF863306E for ; Wed, 30 Jun 2010 17:59:27 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o5UKxOvR017212; Wed, 30 Jun 2010 16:59:24 -0400 (EDT) To: Nathan Robertson cc: pgsql-admin@postgresql.org Subject: Re: cache lookup failed for index In-reply-to: References: <4C2B02040200002500032D63@gw.wicourts.gov> <4C2B0AEF0200002500032D75@gw.wicourts.gov> <4C2B21A00200002500032D8D@gw.wicourts.gov> <11712.1277914463@sss.pgh.pa.us> <12643.1277917499@sss.pgh.pa.us> <15355.1277925611@sss.pgh.pa.us> <16649.1277929815@sss.pgh.pa.us> Comments: In-reply-to Nathan Robertson message dated "Wed, 30 Jun 2010 16:32:15 -0400" Date: Wed, 30 Jun 2010 16:59:24 -0400 Message-ID: <17211.1277931564@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-0.011 tagged_above=-10 required=5 tests=BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201006/239 X-Sequence-Number: 35017 Nathan Robertson 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