Обсуждение: gist DatumGetPointer returns pointer to corrupted data
I index these structures in gist:
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).
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?
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?
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
On Tue, Oct 19, 2010 at 10:23 PM, Robert Haas <robertmhaas@gmail.com> wrote:
Are you refering to table pg_type?
If yes, those type structures exist only in c I didn't write any in-out functions, so they don't exist in sql level.
I pass a different data type (which exists in sql) to compress method which changes it to typ_s_flagged.
The problem occurs in C code. I hope my explanation is clear.
Is pg_type.typlen set correctly?
Are you refering to table pg_type?
If yes, those type structures exist only in c I didn't write any in-out functions, so they don't exist in sql level.
I pass a different data type (which exists in sql) to compress method which changes it to typ_s_flagged.
The problem occurs in C code. I hope my explanation is clear.
> Are you refering to table pg_type? > If yes, those type structures exist only in c I didn't write any in-out > functions, so they don't exist in sql level. Type should have in/out function, at least dummy. If type is not present in pg_type table then postgres can not operate with even on disk. -- Teodor Sigaev E-mail: teodor@sigaev.ru WWW: http://www.sigaev.ru/
2010/10/22 Teodor Sigaev <teodor@sigaev.ru>
Yes, you are right. I did some tests and I found that in order for it to work correctly the type we specify in STORAGE parameter in create operator class has to have internallength same or bigger than the sizeof() struct that is stored in nodes of the tree. I didn't specify storage parameter at all so that was the problem. Thank you for helping.
Type should have in/out function, at least dummy. If type is not present in pg_type table then postgres can not operate with even on disk.
Yes, you are right. I did some tests and I found that in order for it to work correctly the type we specify in STORAGE parameter in create operator class has to have internallength same or bigger than the sizeof() struct that is stored in nodes of the tree. I didn't specify storage parameter at all so that was the problem. Thank you for helping.