Re: Why we panic in pglz_decompress
От | Alvaro Herrera |
---|---|
Тема | Re: Why we panic in pglz_decompress |
Дата | |
Msg-id | 20080229140933.GC4673@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Why we panic in pglz_decompress (Zdenek Kotala <Zdenek.Kotala@Sun.COM>) |
Ответы |
Re: Why we panic in pglz_decompress
Re: Why we panic in pglz_decompress |
Список | pgsql-hackers |
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. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
В списке pgsql-hackers по дате отправления: