upstream/postgresql
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2026-03-31 23:07:04 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

pg_plan_advice: Avoid assertion failure with partitionwise aggregate.

Browse source 
An Append node that is part of a partitionwise aggregate has no
apprelids. If such a node was elided, the previous coding would
attempt to call unique_nonjoin_rtekind() on a NULL pointer, which
leads to an assertion failure. Insert a NULL check to prevent that.

Reported-by: Alexander Lakhin <exclusion@gmail.com>
Discussion: http://postgr.es/m/0afba1ce-c946-4131-972d-191d9a1c097c@gmail.com
This commit is contained in:
Robert Haas 2026-03-30 09:58:25 -04:00
parent 39dcd10a2c
commit e2ee95233c
1 changed files with 7 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
contrib/pg_plan_advice/pgpa_scan.c
View file

@ -68,8 +68,15 @@ pgpa_build_scan(pgpa_plan_walker_context *walker, Plan *plan,
* Note that the PGPA_SCAN_PARTITIONWISE case also includes
* partitionwise joins; this module considers those to be a form of
* scan, since they lack internal structure that we can decompose.
*
* Note also that it's possible for relids to be NULL here, if the
* elided Append node is part of a partitionwise aggregate. In that
* case, it doesn't matter what strategy we choose, but we do need to
* avoid calling unique_nonjoin_rtekind(), which would fail an
* assertion.
*/
if ((nodetype == T_Append || nodetype == T_MergeAppend) &&
relids != NULL &&
unique_nonjoin_rtekind(relids,
walker->pstmt->rtable) == RTE_RELATION)
strategy = PGPA_SCAN_PARTITIONWISE;