"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 6: explain analyze is your friend
