Re: Crashing on insert to GIN index

Jack Orenstein <jao(at)geophile(dot)com> writes:
> I am defining a new type, FooBar, and trying to create a GIN index for it.
> Everything is working well without the index. FooBar values are getting
> into a table, and being retrieved and selected correctly. But I'm getting a
> crash when I add a GIN index on a column of type FooBar.

> Here is the operator class:

> create operator class foobar_ops
> default for type foobar using gin
> as
> operator 1 @@,
> function 1 foobar_cmp(bigint, bigint),
> function 2 foobar_item_to_keys(foobar, internal),
> function 3 foobar_query_to_keys(foobar, internal, int2, internal,
> internal),
> function 4 foobar_match(internal, int2, anyelement, int4, internal,
> internal),
> function 5 foobar_partial_match(foobar, foobar, int2, internal);

Hmm, don't you want a "STORAGE bigint" clause in there?

> And the implementation:

> int64_t* keys = (int64_t*) palloc(sizeof(int64_t));

As a general rule, ignoring the conventions about how to use Datums
is a good way to cause yourself pain. It doesn't look like what
you've shown us so far is directly broken ... as long as you don't
try to run it on 32-bit hardware ... but bugs could easily be lurking
nearby. More, the fact that this code looks nothing like standard
coding for the task is not making your life easier, because you
can't easily compare what you've done to other functions. It'd be
much wiser to write this as

Datum *keys = (Datum *) palloc(sizeof(Datum) * whatever);

and then use Int64GetDatum() to convert your integer key
values to Datums. Yes, I'm well aware that that macro is
physically a no-op (... on 64-bit hardware ...) but you're
best advised to not rely on that, but think of Datum as a
physically distinct type.

regards, tom lane