Teodor Sigaev <teodor@stack.net> writes:
> We have report that all GiST opclasses cause a coredump while creating
> index on 64-bit Solaris. I try to make installcheck GiST's contrib
> modules on DEC Alpha and got the same result. So it may be one
> problem.
Yes. It looks to me like GIST is broken on any platform that has 8-byte
Datum (or pointer) and requires 8-byte alignment of same.
The problem is that GISTENTRY will require 8-byte alignment on such a
platform, and this code is not honoring that: it's trying to set up an
array of GISTENTRYs starting at offset 4 in a palloc'd memory chunk.
Apparently, the reason for the offset is to stick a varlena header on
the parameter being passed to the picksplit function. This seems like
it might be unnecessary. Is there another way for the picksplit
function to learn the length of the array?
I think you have two possible ways to proceed:
1. Modify the code to use MAXALIGN(VARHDRSZ) rather than just VARHDRSZ
as the offset in the bogus bytea construct. This would be messy since
you couldn't use VARDATA() anymore.
2. Forget the bytea header and just treat the object as a GISTENTRY
array.
Either one of these is going to require changing the picksplit functions
as well as the calling code, so they're both bad choices from a
maintenance point of view. I think I lean towards #2 since it will make
the code less ugly rather than more so.
regards, tom lane
