Re: gist DatumGetPointer returns pointer to corrupted data

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Marios Vodas <mvodas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: gist DatumGetPointer returns pointer to corrupted data
Date: 2010-10-19 19:23:43
Message-ID: AANLkTinXQD+36Co0MZpMs0qYRFuBCT4z2BfdJOjzNy7d@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 19, 2010 at 1:46 PM, Marios Vodas <mvodas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-10-19 19:32:57 Re: max_wal_senders must die
Previous Message Simon Riggs 2010-10-19 19:21:01 Re: Issues with two-server Synch Rep