Re: Tagged types module and varlena changes - Mailing list pgsql-general

From Alban Hertroys
Subject Re: Tagged types module and varlena changes
Date
Msg-id 21AD48CF-1868-4632-BC7C-B1B03A27ABEF@solfertje.student.utwente.nl
Whole thread Raw
In response to Re: Tagged types module and varlena changes  (Greg Stark <gsstark@mit.edu>)
Responses Re: Tagged types module and varlena changes  (Alban Hertroys <dalroi@solfertje.student.utwente.nl>)
Re: Tagged types module and varlena changes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On 26 Aug 2009, at 15:33, Greg Stark wrote:

> On Wed, Aug 26, 2009 at 1:14 PM, Alban
> Hertroys<dalroi@solfertje.student.utwente.nl> wrote:
>>> struct varlena* tv = (struct varlena*)tt_palloc( VARSIZE( datum ) );
>>>
>>> tv->vl_len = VARSIZE( datum ) - sizeof(Oid);
>>> memcpy( tv->vl_dat,
>>>        &((struct taggedtypev*)DatumGetPointer( datum ))->val,
>>>        VARSIZE(datum) - sizeof(Oid) - VARHDRSZ );
>>> return PointerGetDatum( tv ) ;
>>
>>
>> This doesn't compile anymore as the vl_len member of struct varlena
>> no
>> longer exists and we're supposed to use the SET_VARSIZE macro
>> instead now.. I
>> tried that, but then the memcpy bails out due to the size
>> calculation being
>> wrong. I don't know enough about varlena usage to figure out what the
>> correct way of calculating the size for memcpy is, or whether that
>> approach
>> is at all feasable with the current varlena implementation. What
>> should the
>> above read?
>>
>
> With the SET_VARSIZE the above should work *as long as datum is not
> toasted (or packed)*. If it's been detoasted then that's good, or if
> it was freshly generated and not stored in a tuple then it should be
> good too.

I changed it to:
>         struct varlena* tv = (struct
> varlena*)tt_palloc( VARSIZE( datum ) );
>         struct taggedtypev *typev =
>         (struct taggedtypev*) DatumGetPointer( datum );
>         int a = VARSIZE(datum) - sizeof(Oid),
>             b = VARSIZE_ANY_EXHDR(datum) - sizeof(Oid);
>
>         SET_VARSIZE(tv->vl_len_, a);
>         memcpy( tv->vl_dat, &typev->val, b );
>
>         return PointerGetDatum( tv ) ;

But still I get a segfault on the memcpy line. The backtrace shows the
following (line 0 is the memcpy itself, nothing useful to see there):

#1  0x29806f74 in ExtractTaggedTypeDatum (tti=0x2980c560,
datum=726659176)
     at taggedtypes.c:249
249                     memcpy( tv->vl_dat, &typev->val, b );
(gdb) print *tv
$1 = {vl_len_ = "\000\000\000", vl_dat = ""}
(gdb) print a
$2 = 0
(gdb) print b
$3 = -4
(gdb) print *typev
$4 = {len = "\020\000\000", tag = 68899, val = "!\000\000"}

Obviously passing a negative value as the size to copy is what's
causing the segfault, but how come it's negative? Could it be that my
table doesn't have Oid's and that subtracting sizeof(Oid) is what
makes the length become negative?

I did some reading up on TOASTing and how to use those macro's, but
the manual wasn't very detailed in this particular area... I doubt my
values are TOASTed though, they're rather short values; not quite 2k
anyway.

Alban Hertroys

--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.


!DSPAM:737,4a954cda11869014116556!



pgsql-general by date:

Previous
From: Gerhard Heift
Date:
Subject: Re: How to create a multi-column index with 2 dates using 'gist'?
Next
From: Fred Janon
Date:
Subject: Re: How to create a multi-column index with 2 dates using 'gist'?