[COMMITTERS] pgsql: Prevent planagg.c from failing on queries containing CTEs. - Mailing list pgsql-committers

From Tom Lane
Subject [COMMITTERS] pgsql: Prevent planagg.c from failing on queries containing CTEs.
Date
Msg-id E1cGrh5-0008CF-MK@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Prevent planagg.c from failing on queries containing CTEs.

The existing tests in preprocess_minmax_aggregates() usually prevent it
from trying to do anything with queries containing CTEs, but there's an
exception: a CTE could be present as a member of an appendrel, if we
flattened a UNION ALL that contains CTE references.  If it did try to
generate an optimized path for a query using a CTE, it failed with
"could not find plan for CTE", as reported by Torsten Förtsch.

The proximate cause is an unwise decision in commit 3fc6e2d7f to clear
subroot->cte_plan_ids in build_minmax_path().  That left the subroot's
cte_plan_ids list out of step with its parse->cteList.

Removing the "subroot->cte_plan_ids = NIL;" assignment is enough to let
the case work again, but really it's pretty silly to be expending any
cycles at all in this module when there are CTEs: we always treat their
outputs as unordered so there's no way for the optimization to win.
Hence, also add an early-exit test so we don't waste time like that.

Back-patch to 9.6 where the misbehavior was introduced.

Report: https://postgr.es/m/CAKkG4_=gjY5QiHtqSZyWMwDuTd_CftKoTaCqxjJ7uUz1-Gw=qw@mail.gmail.com

Branch
------
REL9_6_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/997a2994eef372d06798d2f3409a76098c1590a1

Modified Files
--------------
src/backend/optimizer/plan/planagg.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)


pgsql-committers by date:

Previous
From: Robert Haas
Date:
Subject: [COMMITTERS] pgsql: Fix bug in hashbulkdelete.
Next
From: Tom Lane
Date:
Subject: [COMMITTERS] pgsql: Improve handling of array elements as getdiag_targets andcursor