Why we panic in pglz_decompress

Поиск
Список
Период
Сортировка
От Zdenek Kotala
Тема Why we panic in pglz_decompress
Дата
Msg-id 47C80ED8.9060304@sun.com
обсуждение исходный текст
Ответы Re: Why we panic in pglz_decompress  (Alvaro Herrera <alvherre@commandprompt.com>)
creating new aggregate function  (Justin <justin@emproshunts.com>)
Список pgsql-hackers
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? By my opinion is not too good idea to 
crash server in case when we know how much memory we really have for 
dest and we can check range. Other silly thing is that message 
"compressed data is corrupt" does not contain any information about file 
relation etc.

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).
    Any comments?
        thanks Zdenek


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

Предыдущее
От: "Gurjeet Singh"
Дата:
Сообщение: Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Why we panic in pglz_decompress