Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Paul Ramsey <pramsey@cleverelephant.ca>
Cc: Pgsql Hackers <pgsql-hackers@postgresql.org>, Regina Obe <lr@pcorp.us>, Fredrik Widlert <fredrik.widlert@digpro.se>
Date: 2024-10-09T20:21:53Z
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.

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.

The overall code path here is eval_const_expressions ->
simplify_function -> cost_qual_eval -> estimate_array_length,
and the proximate cause of root being NULL is that
simplify_function/inline_function don't take a root pointer,
so they pass NULL root to cost_qual_eval.

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.

			regards, tom lane