| От | 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 по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера