Recovering (slowly!) from database corruption

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux