Re: gist DatumGetPointer returns pointer to corrupted data - Mailing list pgsql-hackers

From Robert Haas
Subject Re: gist DatumGetPointer returns pointer to corrupted data
Date
Msg-id AANLkTinXQD+36Co0MZpMs0qYRFuBCT4z2BfdJOjzNy7d@mail.gmail.com
Whole thread Raw
In response to gist DatumGetPointer returns pointer to corrupted data  (Marios Vodas <mvodas@gmail.com>)
Responses Re: gist DatumGetPointer returns pointer to corrupted data
List pgsql-hackers
On Tue, Oct 19, 2010 at 1:46 PM, Marios Vodas <mvodas@gmail.com> wrote:
> I index these structures in gist:
>
>> typedef struct {
>>     uint8 type_flag;
>>     float8 xi;
>>     float8 yi;
>>     Timestamp ti;
>>     float8 xe;
>>     float8 ye;
>>     Timestamp te;
>>     int32 id;
>> } typ_s_flagged;
>>
>> typedef struct {
>>     uint8 type_flag;
>>     float8 xl;
>>     float8 yl;
>>     Timestamp tl;
>>     float8 xh;
>>     float8 yh;
>>     Timestamp th;
>> } typ_b_flagged;
>
> typ_s_flagged is the type of leaf entries and typ_b_flagged is for non-leaf
> entries.
> This is how I determine which type it is in functions union, picksplit,
> penalty etc (I tried to use GIST_LEAF but it produced errors in execution
> time!, anyway I know this might not be a best practice but it is not wrong).
>
>> GISTENTRY *entry = (GISTENTRY *) PG_GETARG_POINTER(0); //in penalty,
>> consistent
>>
>> //or GistEntryVector *entryvec = (GistEntryVector *) PG_GETARG_POINTER(0);
>> entry = &entryvec->vector[i]; in union and picksplit
>> uint8 *type_flag = (uint8 *) DatumGetPointer(entry->key);
>> if (*type_flag == 0) {
>>       typ_s_flagged *p1 = (typ_s_flagged *) DatumGetPointer(entry->key);
>> } else if(*type_flag == 1){
>>       typ_b_flagged *p2 = (typ_b_flagged *) DatumGetPointer(entry->key);
>> }
>
>
> The problem is that when I access p1->te or p1->id or p2->th the value I get
> is zeros, for both. But I get correct values for variables before p1->te.
> I checked my code multiple times and I didn't found a mistake like bad size
> in palloc or wrong variable assignment.
> I checked compress function and it seems to accept and return correct
> values.
> Does anyone have any idea on how to solve this? Or why it happens?

Is pg_type.typlen set correctly?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Issues with two-server Synch Rep
Next
From: Tom Lane
Date:
Subject: Re: max_wal_senders must die