Re: Pg17 Crash in Planning (Arrays + Casting + UDF)
От | Nathan Bossart |
---|---|
Тема | Re: Pg17 Crash in Planning (Arrays + Casting + UDF) |
Дата | |
Msg-id | Zwbri-LE-8OJEIlW@nathan обсуждение исходный текст |
Ответ на | Re: Pg17 Crash in Planning (Arrays + Casting + UDF) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Pg17 Crash in Planning (Arrays + Casting + UDF)
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: