From: Robert Haas Date: Mon, 30 Mar 2026 13:58:25 +0000 (-0400) Subject: pg_plan_advice: Avoid assertion failure with partitionwise aggregate. X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=e2ee95233cab32a0d5fe64925aefe816c13dbbc0;p=thirdparty%2Fpostgresql.git pg_plan_advice: Avoid assertion failure with partitionwise aggregate. 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 Discussion: http://postgr.es/m/0afba1ce-c946-4131-972d-191d9a1c097c@gmail.com --- diff --git a/contrib/pg_plan_advice/pgpa_scan.c b/contrib/pg_plan_advice/pgpa_scan.c index 5f210f2b725..0467f9b12ba 100644 --- a/contrib/pg_plan_advice/pgpa_scan.c +++ b/contrib/pg_plan_advice/pgpa_scan.c @@ -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;