Recovering (slowly!) from database corruption

Hi,

We've been working with the excellent Second Quadrant to resolve some
data corruption issues caused by a database crash. I'm trying to get an
explanation of a recurring issue that we're seeing with the database.

Basically, some queries that are run against the DB take the following form;

CREATE TEMP TABLE 'x' ON COMMIT DROP AS SELECT...

>From this, we often get an ERROR and the transaction doesn't complete.
The error message is invariably;

ERROR: cache lookup failed for relation 5168456

Using ois2name has left me more confused, as the provided OID doesn't
seem to existing anywhere in the database. I've read some discussion
from Tom Lane that I didn't really follow on the [HACKERS] list and one
of our consultants mentioned that this might be related to a bug fix
between 8.4.0 and 8.4.1.

Can anyone break this down into SysAdmin (NOT DBA!) language for me? If
it involves reading manuals or whitepapers, that's fine. If it involves
reading source code, I'm game to give it a try. If it involves years of
study in database theory, I think it needs to be a little simpler than
that!!

Many thanks

--
Dave Barton
Senior Systems Administrator - Comodo