Re: BRIN index creation on geometry column causes crash

On 2025-Jan-03, Tomas Vondra wrote:

> Reproduced, but I belive this is actually a long-standing PostGIS bug.
> The exact place where it crashes is here:
>
> /* Finally, merge B to A. */
> finfo = inclusion_get_procinfo(bdesc, attno, PROCNUM_MERGE);
> Assert(finfo != NULL);
> result = FunctionCall2Coll(finfo, colloid, ...);
>
> With asserts, it fails on the assert, i.e. finfo is NULL. This means the
> opfamily is missing the "MERGE" support procedure, which is however
> required (from the very beginning of BRIN in 9.5).

Hmm, I completely agree that this is a PostGIS bug, but at the same time
I think it's wrong for Postgres not to verify that the support function
exists, so that we can throw an error instead of crashing. I think the
most expedient way to implement this is to add a "missing_ok" argument
to the various "foo_get_procinfo" functions, and make to pass it true
only in cases where the usage of the return value already admit that it
could be a null pointer (meaning it's really an optional support proc).

This should avoid further crashes with invalidly defined opclasses; see
attached POC patch. The user is still in a bad place, because for
instance if it's autovacuum that tries to do the range merging, then
vacuuming will fail but people may not notice for months unless they're
paying careful attention to the server logs. Crashing is good (tm)
because now a bunch of people are aware that the opclass is broken.

My next question is why didn't brinvalidate detect this problem. Is it
just that nobody ran 'amvalidate' on the opclass, or is it that
brinvalidate does not know that it needs to require the merge proc? But
I'll leave that for later.

Now, in writing this patch I noticed that both brin_bloom.c and
brin_minmax_multi.c seem to have cargo-culted the idea that support
procs can be optional; both of them have a single support proc
(PROCNUM_HASH and PROCNUM_DISTANCE, respectively) which is not optional;
so the "extra_proc_missing" stuff seems unnecessary for them. And
therefore the new missing_ok support I introduce in this patch would
also be unnecessary. As far as I can tell, there are no ABI concerns
about removing opaque->extra_proc_missing[] from both these opclass
scaffolds (and reintroducing it later, if we determine that we do need
optional support procs in those scaffolds after all.)

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"Saca el libro que tu religión considere como el indicado para encontrar la
oración que traiga paz a tu alma. Luego rebootea el computador
y ve si funciona" (Carlos Duclós)