Re: Something's not (de)compressing right

Поиск
Список
Период
Сортировка
От Elliot Lee
Тема Re: Something's not (de)compressing right
Дата
Msg-id Pine.LNX.4.58.0312021604260.20158@devserv.devel.redhat.com
обсуждение исходный текст
Ответы Re: Something's not (de)compressing right  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
http://archives.postgresql.org/pgsql-hackers/2000-07/msg00483.php

I'm having this same problem with postgresql 7.3.4. Easy to reproduce by 
running an 'INSERT' query. Here is some of the debugging info if I break 
near the beginning of the pglz_decompress function:

(gdb) p dend
$1 = (unsigned char *) 0xc47f0602 <Address 0xc47f0602 out of bounds>
(gdb) p dp
$2 = (unsigned char *) 0xb605153c ""
(gdb) p *source
$3 = {varsize = 1316614350, rawsize = 2328}
(gdb) up
#1  0x0807c0b0 in heap_tuple_untoast_attr (attr=0xb6051534)   at tuptoaster.c:151
151                     pglz_decompress((PGLZ_Header *) attr, 
VARATT_DATA(result));
(gdb) p *attr
$4 = {va_header = 1316614350, va_content = {va_compressed = {     va_rawsize = 2328, va_data = ""}, va_external =
{va_rawsize= 2328,     va_extsize = 786432, va_valueid = 1048579,     va_toastrelid = 1316614344}, va_data = "\030"}}
 

Ideas? Any more information I can provide? Looks like the bad value is
coming in through 'dend', but I don't understand VARATT_SIZE well enough
to know where the bad value is coming from.

Ciao,
-- Elliot
"The mark of an immature man is that he wants to die nobly for a cause,
while the mark of a mature man is that he wants to live humbly for
one."


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

Предыдущее
От: Randolf Richardson
Дата:
Сообщение: Re: *sigh*
Следующее
От: elein
Дата:
Сообщение: [fwd: [GENERAL] Domains and function]