Re: BRIN index creation on geometry column causes crash

On Fri, 3 Jan 2025 at 11:02, Tobias Wendorff
<tobias.wendorff@tu-dortmund.de> wrote:
>
> ```sql
> DROP TABLE IF EXISTS random_points;
> CREATE TABLE random_points AS
> SELECT ST_MakePoint(0, 0) AS geom FROM generate_series(1, 130_561);
> CREATE INDEX ON random_points USING brin(geom);
> ```

> ### Actual behavior
> The server terminates abruptly during index creation with the following
> error:
> ```
> server closed the connection unexpectedly

Thanks for the report.  That's certainly a bug.

What seems to be going on is that the following code in
brin_inclusion_union() looks for the function for the PROCNUM_MERGE
strategy but cannot find it, and not finding it shouldn't result in a
crash. The code does:

finfo = inclusion_get_procinfo(bdesc, attno, PROCNUM_MERGE);
Assert(finfo != NULL);

I built with Asserts enabled and that Assert triggers for me.

The other strategy types seem to check for NULLs with:

finfo = inclusion_get_procinfo(bdesc, attno, PROCNUM_MERGEABLE);
if (finfo != NULL &&

It seems, going by the following comment that PROCNUM_MERGE isn't
optional, which probably explains about the lack of NULL check for
that strategy, however, I don't see any code anywhere which checks to
make sure it exists before we get to this point.

#define PROCNUM_MERGE 11 /* required */

I see PostGIS sets this up with the following:

CREATE OPERATOR CLASS brin_geography_inclusion_ops
  DEFAULT FOR TYPE geography
  USING brin AS
    FUNCTION      1        brin_inclusion_opcinfo(internal),
    FUNCTION      2        geog_brin_inclusion_add_value(internal,
internal, internal, internal),
    FUNCTION      3        brin_inclusion_consistent(internal,
internal, internal),
    FUNCTION      4        brin_inclusion_union(internal, internal, internal),
    OPERATOR      3        &&(geography, geography),
    OPERATOR      3        &&(geography, gidx),
    OPERATOR      3        &&(gidx, geography),
    OPERATOR      3        &&(gidx, gidx),
  STORAGE gidx;

I've copied in Álvaro, as he knows this code much better than I do.

David