From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: Fix planner error (or assert trap) with nested set operations. |
Date: | 2017-04-07 16:18:48 |
Message-ID: | E1cwWb2-0006YK-2u@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Fix planner error (or assert trap) with nested set operations.
As reported by Sean Johnston in bug #14614, since 9.6 the planner can fail
due to trying to look up the referent of a Var with varno 0. This happens
because we generate such Vars in generate_append_tlist, for lack of any
better way to describe the output of a SetOp node. In typical situations
nothing really cares about that, but given nested set-operation queries
we will call estimate_num_groups on the output of the subquery, and that
wants to know what a Var actually refers to. That logic used to look at
subquery->targetList, but in commit 3fc6e2d7f I'd switched it to look at
subroot->processed_tlist, ie the actual output of the subquery plan not the
parser's idea of the result. It seemed like a good idea at the time :-(.
As a band-aid fix, change it back.
Really we ought to have an honest way of naming the outputs of SetOp steps,
which suggests that it'd be a good idea for the parser to emit an RTE
corresponding to each one. But that's a task for another day, and it
certainly wouldn't yield a back-patchable fix.
Report: https://postgr.es/m/20170407115808.25934.51866@wrigleys.postgresql.org
Branch
------
REL9_6_STABLE
Details
-------
http://git.postgresql.org/pg/commitdiff/c0a493e17cc3b99b6d625d5818dc9b504a54d360
Modified Files
--------------
src/backend/optimizer/prep/prepunion.c | 12 +++++++++++-
src/test/regress/expected/union.out | 25 +++++++++++++++++++++++++
src/test/regress/sql/union.sql | 6 ++++++
3 files changed, 42 insertions(+), 1 deletion(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2017-04-07 16:20:29 | pgsql: Remove duplicate assignment. |
Previous Message | Kevin Grittner | 2017-04-07 16:06:37 | Re: pgsql: Add infrastructure to support EphemeralNamedRelation references. |