Re: GIST code doesn't build on strict 64-bit machines
От | Teodor Sigaev |
---|---|
Тема | Re: GIST code doesn't build on strict 64-bit machines |
Дата | |
Msg-id | 40684A5D.9060605@sigaev.ru обсуждение исходный текст |
Ответ на | Re: GIST code doesn't build on strict 64-bit machines (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: GIST code doesn't build on strict 64-bit machines
|
Список | pgsql-hackers |
>>>I suppose that a correct fix involves doing MAXALIGN(VARDATA(evec)), >>>but I do not know what places need to change to support this. > > >>Its only union and picksplit user-defined methods in contrib modules. > > > If I recall correctly, we decided to go with the present hack because we > found the problem just before a release date and there wasn't time to do > it more cleanly. It seems to me that there is time to fix it right for > 7.5 ... Yes, you are right. I suggest to replace bytea by struct typedef struct {int32 n; /* number of GISTENTRY */GISTENTRY vector[1]; } GistEntryVector; #define GEVHDRSZ (MAXALIGN(sizeof(int32)) so, allocation will be: evec = palloc( GEVHDRSZ + sizeof(GISTENTRY)*n ); MAXALIGN guarantee that allocated memory will be no less than required (it may be greater for 4 bytes). And change interface to user defined structures from Datum union(bytea *entryvec, int *size) Datum picksplit(bytea *entryvec, GIST_SPLITVEC *v) to Datum union(GistEntryVector *entryvec, int *size) Datum picksplit(GistEntryVector *entryvec, GIST_SPLITVEC *v) In this function it's need to use entryvec->n and entryvec->vector We can do even Datum union(int32 n, GISTENTRY *entryvec, int *size) Datum picksplit(int32 n, GISTENTRY *entryvec, GIST_SPLITVEC *v) It seems to me that first case is clearer. Of course, I change all contrib modules to new interface. What do you think? -- Teodor Sigaev E-mail: teodor@sigaev.ru
В списке pgsql-hackers по дате отправления: