From: | tgl(at)postgresql(dot)org (Tom Lane) |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: Fix mis-calculation of extParam/allParam sets for plan nodes, as |
Date: | 2008-07-10 01:17:45 |
Message-ID: | 20080710011745.0B98A754857@cvs.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Log Message:
-----------
Fix mis-calculation of extParam/allParam sets for plan nodes, as seen in
bug #4290. The fundamental bug is that masking extParam by outer_params,
as finalize_plan had been doing, caused us to lose the information that
an initPlan depended on the output of a sibling initPlan. On reflection
the best thing to do seemed to be not to try to adjust outer_params for
this case but get rid of it entirely. The only thing it was really doing
for us was to filter out param IDs associated with SubPlan nodes, and that
can be done (with greater accuracy) while processing individual SubPlan
nodes in finalize_primnode. This approach was vindicated by the discovery
that the masking method was hiding a second bug: SS_finalize_plan failed to
remove extParam bits for initPlan output params that were referenced in the
main plan tree (it only got rid of those referenced by other initPlans).
It's not clear that this caused any real problems, given the limited use
of extParam by the executor, but it's certainly not what was intended.
I originally thought that there was also a problem with needing to include
indirect dependencies on external params in initPlans' param sets, but it
turns out that the executor handles this correctly so long as the depended-on
initPlan is earlier in the initPlans list than the one using its output.
That seems a bit of a fragile assumption, but it is true at the moment,
so I just documented it in some code comments rather than making what would
be rather invasive changes to remove the assumption.
Back-patch to 8.1. Previous versions don't have the case of initPlans
referring to other initPlans' outputs, so while the existing logic is still
questionable for them, there are not any known bugs to be fixed. So I'll
refrain from changing them for now.
Tags:
----
REL8_2_STABLE
Modified Files:
--------------
pgsql/src/backend/executor:
execAmi.c (r1.89.2.1 -> r1.89.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execAmi.c?r1=1.89.2.1&r2=1.89.2.2)
pgsql/src/backend/optimizer/plan:
subselect.c (r1.112.2.3 -> r1.112.2.4)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/subselect.c?r1=1.112.2.3&r2=1.112.2.4)
pgsql/src/test/regress/expected:
subselect.out (r1.14.2.1 -> r1.14.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/subselect.out?r1=1.14.2.1&r2=1.14.2.2)
pgsql/src/test/regress/sql:
subselect.sql (r1.9.2.1 -> r1.9.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/subselect.sql?r1=1.9.2.1&r2=1.9.2.2)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-07-10 01:17:52 | pgsql: Fix mis-calculation of extParam/allParam sets for plan nodes, as |
Previous Message | Tom Lane | 2008-07-10 01:17:36 | pgsql: Fix mis-calculation of extParam/allParam sets for plan nodes, as |