>>>>> "Thomas" == Thomas Munro <thomas.munro@enterprisedb.com> writes:
Thomas> So it's not the reading of the tuple queue per se, but the
Thomas> resulting visit to a higher part of the plan when the Gather
Thomas> node emits a tuple. It can't be right that plan id 2 and plan
Thomas> id 0 are both using paramno 0, can it? I'm not too familiar
Thomas> with the planner code that allocates those but will go and poke
Thomas> at it.
Looks like this isn't a new bug, either; I can reproduce it on 10.x.
So I think you're right to finger the planner's allocation of params as
the culprit. Looking at replace_nestloop_params_mutator, it's keeping a
list of nestloop params in root->curOuterParams (thus, globally to the
whole subquery being planned), and it assumes that if equal() is true
between the value of an existing nestloop param (which must be a Var)
and the Var for the one it's trying to create, then it's ok to use the
existing one.
But clearly this can't work if one param is referenced both inside and
outside a Gather, because while they will compare equal for Vars, they
won't actually have the same value thanks to rows coming in from
workers.
--
Andrew (irc:RhodiumToad)
