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

Hi,

On 2023-02-21 19:00:07 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > Perhaps we should deal with this by generating a distinct type of expression
> > step, that looks up information about the param in a different place? Nothing
> > forces us to have the expression step look into
> > prm = &(econtext->ecxt_param_exec_vals[op->d.param.paramid]);
>
> Right, where I was going was to have a distinct EEOP type that finds
> the ParamExecData in some other way. The main question is where to keep
> that not-so-global ParamExecData.

We currently overwrite prm->execPlan in ExecInitSubPlan(), when creating a
second reference to the subplan. Which is why we then end up using the wrong
SubPlanState in ExecSetParamPlan().

The problem of using the wrong SubPlanState doesn't look too hard to solve: We
could stash the "actual" execPlan in scratch.d.param.something, instead of
looking it up during ExecEvalParamExec().

I think that'd not be quite enough, because due to sharing the same
ParamExecData, we wouldn't know when to recompute the plan.

It also looks like something might not yet quite compute/adjust the types
completely enough in execPartition.c...

Greetings,

Andres Freund