From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Michael Paquier <michael@paquier.xyz>, exclusion@gmail.com,
        pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible
 fields that leads to a server crash
In-reply-to: <20230225201942.bildwmfri625pugq@awork3.anarazel.de>
References: <718944.1677189963@sss.pgh.pa.us>
 <20230223233636.zkt4tqzsc4b6ekwn@awork3.anarazel.de>
 <20230224015417.75yimxbksejpffh3@awork3.anarazel.de>
 <851179.1677259566@sss.pgh.pa.us>
 <20230224174412.xk3y364t6a2udp5t@awork3.anarazel.de>
 <1060251.1677276763@sss.pgh.pa.us>
 <20230224225357.2orpiokrfpjllfm4@awork3.anarazel.de>
 <1073422.1677282550@sss.pgh.pa.us>
 <20230224235704.jz5ayb37x6miml6v@awork3.anarazel.de>
 <1408832.1677354333@sss.pgh.pa.us>
 <20230225201942.bildwmfri625pugq@awork3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Sat, 25 Feb 2023 12:19:42 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1416231.1677358550.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 25 Feb 2023 15:55:50 -0500
Message-ID: <1416232.1677358550@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1416232.1677358550%40sss.pgh.pa.us>
Precedence: bulk

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 cl=
ones
>     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 f=
or
> initplans? I couldn't find any with a quick assertion. ISTM that that la=
rgely
> 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