Re: Corrupted Table

"Bryan White" <bryan(at)arcamax(dot)com> writes:
>> I concur that this probably indicates corrupted data in the file. We
>> may or may not be able to guess how it got corrupted, but a stack trace
>> seems like the place to start.

> Here is the backtrace:
> #0 0x808b0e1 in CopyTo ()

Hmm. Assuming that it is a corrupted-data issue, the only likely
failure spot that I see in CopyTo() is the heap_getattr macro.
A plausible theory is that the length word of a variable-length field
(eg, text column) has gotten corrupted, so that when the code tries to
access the next field beyond that, it calculates a pointer off the end
of memory.

You will probably find that plain SELECT will die too if it tries to
extract data from the corrupted tuple or tuples. With judicious use of
SELECT last-column ... LIMIT you might be able to narrow down which
tuples are bad, and then dump out the disk block containing them (use
the 'tid' pseudo-attribute to see which block a tuple is in). I'm not
sure if the exercise will lead to anything useful or not, but if you
want to pursue it...

regards, tom lane