| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash |
| Date: | 2023-02-25 20:19:42 |
| Message-ID: | 20230225201942.bildwmfri625pugq@awork3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2023-02-25 20:38:01 | Re: BUG #17744: Fail Assert while recoverying from pg_basebackup |
| Previous Message | Tom Lane | 2023-02-25 19:45:33 | Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash |