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

Hi,

On 2023-02-21 07:49:25 +0900, Michael Paquier wrote:
> On Sat, Feb 18, 2023 at 08:00:00AM +0000, PG Bug reporting form wrote:
> > By comparing two callstacks I can see that in the second case
> > ExecInterpExprStillValid() is executed after the latest
> > ExecEvalExprSwitchContext().
> > The ExecInterpExprStillValid() function contains:
> >         /* skip the check during further executions */
> >         state->evalfunc = (ExprStateEvalFunc) state->evalfunc_private;
> > 
> > If just call evalfunc_private() here, the first case ends with the error as
> > expected.
> 
> Yeah, it would sound logic to me to have consistency with the
> ExecEvalExprSwitchContext() checks here, so it seems like the executor
> has missed the call for a long time.  Would you like to write a patch,
> perhaps?  Did you bisect the origin of that?

What inconsistency / missed call? We use ExecInterpExprStillValid() on the
first execution, but not on later executions. I don't see cases where we omit
calls to ExecInterpExprStillValid().

Afaict this is a problem of a wrongly generated target list, which isn't what
ExecInterpExprStillValid() guards against:
    /*
     * First time through, check whether attribute matches Var.  Might not be
     * ok anymore, due to schema changes. We do that by setting up a callback
     * that does checking on the first call, which then sets the evalfunc
     * callback to the actual method of execution.
     */
    state->evalfunc = ExecInterpExprStillValid;

Greetings,

Andres Freund