Re: Consistent segfault in complex query

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> So I can see exactly where the problem is, but I'm not sure what the
> solution should be.

> EvalPlanQualStart copies the param_exec value list explicitly _not_
> including the execPlan link, which obviously isn't going to work if the
> value has not been computed yet. Should it be forcing the evaluation of
> initplans that haven't been run yet, or should the EPQ scan evaluate
> them itself from a copy of the plan, or does there need to be some way
> to share state? (having the InitPlan be run more than once might be a
> problem?)

The second of those; what we need is for any referenced InitPlans to be
executed afresh under EPQ rules. (I'm not entirely sure that an InitPlan
could need to see different input tuples under EPQ than it'd see
otherwise, but I'm not sure it couldn't, either.) Also, copying the
execPlan links would be bad because it'd allow EPQ to execute planstate
subtrees that are outside the portion of the planstate tree that it made
a working copy of, which doesn't seem safe (e.g., the planstates could
easily have dependencies on the particular EState they are children of).

I think that the expectation of this code was that empty execPlan
links would be filled at need during EvalPlanQualStart's ExecInitNode
calls. That's not happening because the InitPlan we're concerned about
is not attached to any plan node in the part of the tree that we copied;
it's attached to the ModifyTable node itself. We could fix that for
the particular scenario we're looking at here, perhaps by having such
initplans be initialized the same way EvalPlanQualStart treats subplans.
I'm worried though about whether any referenceable initplans might be
attached even higher in the plan tree. If we can ensure that the planner
will never do that, then a fix along these lines should be fairly
straightforward.

regards, tom lane