Horton

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

Joe Conway <mail@joeconway.com>

View thread
From: Joe Conway <mail@joeconway.com>
To: Paul Ramsey <pramsey@cleverelephant.ca>, Pgsql Hackers <pgsql-hackers@postgresql.org>
Cc: Regina Obe <lr@pcorp.us>, Fredrik Widlert <fredrik.widlert@digpro.se>
Date: 2024-10-09T20:15: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 10/9/24 14:52, Paul Ramsey wrote:
> Hackers,
> 
> 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].
> 
> CREATE TABLE n (i integer);
> 
> CREATE OR REPLACE FUNCTION add(integer)
>      RETURNS integer
>      AS 'SELECT 2 * $1 + 4 * $1'
>      LANGUAGE 'sql' IMMUTABLE STRICT PARALLEL SAFE;
> 
> SELECT add(array_length(array_agg(i)::numeric[],1)::integer) FROM n;
> 
> The stack trace shows it doesn’t get past planning, and in fact it doesn’t care if the table has data in it or not.


I can duplicate the crash on master and 17 stable branches, but not pg16 
FWIW. That is as far as I have looked so far.

-- 
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com