Thread: pgsql: Fix mis-calculation of extParam/allParam sets for plan nodes, as
pgsql: Fix mis-calculation of extParam/allParam sets for plan nodes, as
From
tgl@postgresql.org (Tom Lane)
Date:
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_3_STABLE Modified Files: -------------- pgsql/src/backend/executor: execAmi.c (r1.94 -> r1.94.2.1) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execAmi.c?r1=1.94&r2=1.94.2.1) pgsql/src/backend/optimizer/plan: planagg.c (r1.36.2.1 -> r1.36.2.2) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/planagg.c?r1=1.36.2.1&r2=1.36.2.2) subselect.c (r1.129.2.1 -> r1.129.2.2) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/subselect.c?r1=1.129.2.1&r2=1.129.2.2) pgsql/src/test/regress/expected: subselect.out (r1.16.2.1 -> r1.16.2.2) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/subselect.out?r1=1.16.2.1&r2=1.16.2.2) pgsql/src/test/regress/sql: subselect.sql (r1.11.2.1 -> r1.11.2.2) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/subselect.sql?r1=1.11.2.1&r2=1.11.2.2)