Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Zdenek Kotala wrote:
>> I'm now looking into toast code and I found following code in
>> pglz_decompress:
>>
>> 00704 if (destsize != source->rawsize)
>> 00705 elog(destsize > source->rawsize ? FATAL : ERROR,
>> 00706 "compressed data is corrupt");
>>
>>
>> I'm surprise why we there panic?
> Agreed, FATAL is too strong.
Did either of you read the comment just before this code? The reason
it's panicing is that it's possibly already tromped on some critical
data structure inside the backend.
>> My idea is to improve this piece of code and move error logging to
>> callers (heap_tuple_untoast_attr() and heap_tuple_untoast_attr_slice())
>> where we have a little bit more details (especially for external
>> storage).
> Why move it? Just adding errcontext in the callers should be enough.
AFAIR this error has never once been reported from the field, so I don't
see the point of investing a lot of effort in 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
