Re: Why we panic in pglz_decompress

Поиск
Список
Период
Сортировка
От Zdenek Kotala
Тема Re: Why we panic in pglz_decompress
Дата
Msg-id 47C81FD5.9000406@sun.com
обсуждение исходный текст
Ответ на Re: Why we panic in pglz_decompress  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
Alvaro Herrera napsal(a):
> 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.
> 
>> 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.

Good idea.
    thanks Zdenek


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Florian G. Pflug"
Дата:
Сообщение: Re: Read-ahead and parallelism in redo recovery
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Why we panic in pglz_decompress