Re: Something's not (de)compressing right

From: Elliot Lee <sopwith(at)redhat(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Something's not (de)compressing right
Date: 2003-12-02 21:11:21
Message-ID: Pine.LNX.4.58.0312021604260.20158@devserv.devel.redhat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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."

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gaetano Mendola 2003-12-02 23:29:43 Re: rebuilding rpm for RH9 error
Previous Message Vivek Khera 2003-12-02 20:37:40 autovacuum daemon stops doing work after about an hour