Re: Crashing on insert to GIN index

Thank you, the missing STORAGE clause was the problem.

As for the non-standard coding: I did start out with more correct coding,
and it wandered off as I tried to figure out what was causing the crash.

Jack Orenstein

On Sun, Jan 3, 2021 at 7:57 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 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
>