Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash - Mailing list pgsql-bugs

From Andres Freund
Subject Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash
Date
Msg-id 20230225201942.bildwmfri625pugq@awork3.anarazel.de
Whole thread Raw
In response to Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Hi,

On 2023-02-25 14:45:33 -0500, Tom Lane wrote:
> Done like that.

Thanks!


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.

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(). Do
we have cases where the same initplan (with the same paramids, obviously), is
used by multiple nodes?

Greetings,

Andres Freund



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash
Next
From: Thomas Munro
Date:
Subject: Re: BUG #17744: Fail Assert while recoverying from pg_basebackup