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
creating new aggregate function |
Список | 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 по дате отправления: