Hi Tom,
Hmm .. Interesting. A few weeks back I had a corrupted table (due to a
disk error). I temporarily set zero_damaged_pages and vacuumed the
tables concerned. Now that I look back through the logs, the affected
table was utrancell_oo_13642. The fact that the number on the end was
the same means that the table contained data from the same day as the
one that is now giving trouble (ie. This table was being populated on
the same day as carrier_on_13642). Maybe the carrier table was also
corrupted by the disk error (although I did not notice any problem at
the time).
Thanks for the info. I will try to locate the corrupted row(s), maybe
pg_filedump can help with that.
Regards // Mike
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Saturday, 26 May 2007 9:38 AM
To: Michael Harris (BR/EPA)
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] ERROR: cache lookup failed for type 0
"Michael Harris \(BR/EPA\)" <michael.harris@ericsson.com> writes:
> None of the typeid atttypid fields were 0:
Hmm, but you've got a couple of bigint-array columns:
> 167581 | pmtransmittedcarrierpower | 1016 | -1 |
> -1 | 4 | 0 | -1 | -1 | f | x
> | d | f | f | f | f |
> 1
> 167581 | pmaveragerssi | 1016 | -1 |
> -1 | 5 | 0 | -1 | -1 | f | x
> | d | f | f | f | f |
> 1
So that leads to a theory I didn't think of before, which is that this
is not catalog corruption but data corruption. Array values include the
type OID of their elements (to allow a single array_out function to
print the contents of any array value). If you had a row in which one
of these fields had got zeroed out somehow, the error would be
explainable.
> What does "ERROR: cache lookup failed for type 0" mean?
It means some bit of code tried to look up a pg_type entry for type OID
0, which can't possibly be a valid type OID. So wherever the bit of
code got that OID from is corrupted.
You could possibly learn a bit more by doing "\set VERBOSITY verbose"
in psql before provoking the error; that would tell you exactly which
bit of code is trying to look up the bad OID. Using gdb to get a stack
trace from the errfinish call would be even more informative, if you
have a debug-enabled build. But I suspect at this point that it's a
corrupt-data problem and you should attack it on the basis of figuring
out just which row contains the bad value, so you can fix or delete it.
regards, tom lane
