Horton

Re: Pg17 Crash in Planning (Arrays + Casting + UDF)

Nathan Bossart <nathandbossart@gmail.com>

View thread
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Paul Ramsey <pramsey@cleverelephant.ca>, Pgsql Hackers <pgsql-hackers@postgresql.org>, Regina Obe <lr@pcorp.us>, Fredrik Widlert <fredrik.widlert@digpro.se>
Date: 2024-10-09T20:46:03Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Avoid crash in estimate_array_length with null root pointer.

  2. Teach estimate_array_length() to use statistics where available.

On Wed, Oct 09, 2024 at 04:21:53PM -0400, Tom Lane wrote:
> Paul Ramsey <pramsey@cleverelephant.ca> writes:
>> This extremely odd case [2] came in via a report using a lot of PostGIS
>> functions, but it can be reconfigured into a pure-PostgreSQL crasher
>> [1].
> 
> Thanks for the report!  Looks like estimate_array_length() is
> incautiously assuming that the "root" pointer it receives will
> never be NULL.

Yup, git-bisect points me to commit 9391f71.

> We could change their signatures ... but it's explicitly documented
> that eval_const_expressions allows NULL for root, so there would
> presumably still be code paths that'd fail.  It looks like the only
> safe fix is to ensure that estimate_array_length will cope with NULL
> for root.

Do you mean something like this?

-    else if (arrayexpr)
+    else if (arrayexpr && root != NULL)

That'd at least be no worse than how it worked before
estimate_array_length() tried to use statistics, so that seems reasonable
to me.

-- 
nathan