Feedback-ID: ia2694551:Fastmail
Date: Tue, 11 Mar 2025 12:56:15 +0100
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@alvh.no-ip.org>
To: Tomas Vondra <tomas@vondra.me>
Cc: Tobias Wendorff <tobias.wendorff@tu-dortmund.de>,
	pgsql-bugs@lists.postgresql.org
Subject: Re: BRIN index creation on geometry column causes crash
Message-ID: <202503111156.7r3d2gwvc3fn@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <b32735cc-317f-4da6-b76b-e30398f4e94e@vondra.me>
Archived-At: 
 <https://www.postgresql.org/message-id/202503111156.7r3d2gwvc3fn%40alvherre.pgsql>
Precedence: bulk

On 2025-Feb-12, Tomas Vondra wrote:

> On 2/12/25 11:55, Álvaro Herrera wrote:

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

> Yeah, I'm not opposed to doing this. I don't know what's the right level
> of paranoia when dealing with user-defined stuff.

Yeah, I think "make sure we don't crash" is better.  I've pushed this to
all live branches now.

> But if I get this right, this is merely a mitigation turning a crash
> into ERROR, it would not help with detecting the opclass brokenness any
> earlier. Until the parallel builds it was very rare to need the MERGE.

True.  The final fix belongs in the PostGIS opclass definition.  With
this patch, you can still have an index defined with a bogus opclass,
but we won't crash anymore.

> > My next question is why didn't brinvalidate detect this problem.
> 
> I don't know. Either no one tried running it, or maybe it wasn't quite
> clear which of the reported issues are serious and which can be ignored.
> I certainly wasn't quite clear to me when I tried running it, because
> all the messages are INFO, it doesn't say which functions are missing,
> and at least some of it seemed to be due to cross-type operators.
> 
> See this for details:
> 
> https://lists.osgeo.org/pipermail/postgis-devel/2025-January/030457.html

Ugh.  Yeah, this report does not appear to be good enough -- it's far
too noisy and at the same time not detailed enough.  And maybe we're
missing some detailed guidance on what to do about each of those errors.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/