pgsql: Fix create_scan_plan's handling of sortgrouprefs for physicaltl - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Fix create_scan_plan's handling of sortgrouprefs for physicaltl
Date
Msg-id E1fdKkE-0007Lb-Fq@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Fix create_scan_plan's handling of sortgrouprefs for physical tlists.

We should only run apply_pathtarget_labeling_to_tlist if CP_LABEL_TLIST
was specified, because only in that case has use_physical_tlist checked
that the labeling will succeed; otherwise we may get an "ORDER/GROUP BY
expression not found in targetlist" error.  (This subsumes the previous
test about gating_clauses, because we reset "flags" to zero earlier
if there are gating clauses to apply.)

The only known case in which a failure can occur is with a ProjectSet
path directly atop a table scan path, although it seems likely that there
are other cases or will be such in future.  This means that the failure
is currently only visible in the v10 branch: 9.6 didn't have ProjectSet,
while in v11 and HEAD, apply_scanjoin_target_to_paths for some weird
reason is using create_projection_path not apply_projection_to_path,
masking the problem because there's a ProjectionPath in between.

Nonetheless this code is clearly wrong on its own terms, so back-patch
to 9.6 where this logic was introduced.

Per report from Regina Obe.

Discussion: https://postgr.es/m/001501d40f88$75186950$5f493bf0$@pcorp.us

Branch
------
REL9_6_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/4b8860e2dd910a2b6c417b0bac98f12ea55edebb

Modified Files
--------------
src/backend/optimizer/plan/createplan.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)


pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql: Fix bugs with degenerate window ORDER BY clauses inGROUPS/RANGE
Next
From: Tom Lane
Date:
Subject: pgsql: Mark built-in btree comparison functions as leakproof whereit's