Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash

Andres Freund <andres@anarazel.de> writes:
> Your commit message referenced commit 3f7323cbb, which contains:

>     That technique is borrowed from the far older code that supports
>     initplans, and it works okay in that case because the cloned SubPlan nodes
>     are essentially identical.  So it doesn't matter which one of the clones
>     the shared ParamExecData.execPlan field might point to.

Yeah, I now think that was a bit of a misstatement; not about the bug,
but about what happens with initplans.

> Out of curiosity: Are there cases where we actually overwrite execPlan for
> initplans? I couldn't find any with a quick assertion. ISTM that that largely
> should be prevented by initplans being initialized once, in ExecInitNode().

True.  Even if an initplan is referenced in multiple places, it will be
attached to just one plan node's initPlan list, so there should be only
one time that execPlan gets set (per execution cycle of that node), and
I think only one SubPlanState that it could point to.  The references
aren't SubPlan nodes, just Params.

			regards, tom lane