From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Paul Ramsey <pramsey(at)cleverelephant(dot)ca>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>, Regina Obe <lr(at)pcorp(dot)us>, Fredrik Widlert <fredrik(dot)widlert(at)digpro(dot)se> |
Subject: | Re: Pg17 Crash in Planning (Arrays + Casting + UDF) |
Date: | 2024-10-09 20:46:03 |
Message-ID: | Zwbri-LE-8OJEIlW@nathan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 09, 2024 at 04:21:53PM -0400, Tom Lane wrote:
> Paul Ramsey <pramsey(at)cleverelephant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-10-09 20:51:47 | Re: Pg17 Crash in Planning (Arrays + Casting + UDF) |
Previous Message | Jonathan S. Katz | 2024-10-09 20:44:43 | Re: sunsetting md5 password support |