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:[EMAIL PROTECTED] 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\)" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
