Re: Large Database \d: ERROR: cache lookup failed for relation ...

From: "Erik Jones" <mage2k(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Cc: dev(at)myemma(dot)com
Subject: Re: Large Database \d: ERROR: cache lookup failed for relation ...
Date: 2007-06-04 21:36:40
Message-ID: 86ac1b9c0706041436l7efa53d2k2dccb4f741f84c42@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Thomas F. O'Connell" <tf ( at ) o ( dot ) ptimized ( dot ) com> writes:
> I'm dealing with a database where there are ~150,000 rows in
> information_schema.tables. I just tried to do a \d, and it came back
> with this:

> ERROR: cache lookup failed for relation [oid]

> Is this indicative of corruption, or is it possibly a resource issue?

Greetings,

This message is a follow-up to Thomas's message quoted above (we're working
together on the same database). He received one response when he sent the
above message which was from Tom Lane and can be easily summarized as him
having said that that could happen tables were being created or dropped
while running the \d in psql. Unfortunately, that wasn't the case, we have
now determined that there is some corruption in our database and we are
hoping some of you back-end gurus might have some suggestions.

How we verified that there is corruption was simply to reindex all of our
tables in addition to getting the same errors when running a dump this past
weekend. We so far have a list of five tables for which reindex fails with
the error: "ERROR: could not open relation with OID xxxx" (sub xxxx with the
five different #s). After dropping all of the indexes on these tables (a
couple didn't have any to begin with), we still cannot run reindex on them.
In addition, we can't drop the tables either. We can however run alter table
statements on them. So, we have scheduled a downtime for an evening later
this week wherein we plan on bringing the database down for a REINDEX
SYSTEM. Is there anything else anyone can think of that we can do to narrow
down where the actual corruption is or how to fix it?

--
Erik Jones
mage2k(at)gmail(dot)com

Browse pgsql-general by date

  From Date Subject
Next Message Erwin Brandstetter 2007-06-04 22:36:02 Re: SELECT <all fields except "bad_field"> from mytbl;
Previous Message Michael Glaesemann 2007-06-04 21:15:21 Re: Inserting a path into Database