Re: BUG #18830: ExecInitMerge Segfault on MERGE

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> 于2025年3月13日周四 03:23写道：

> On Wed, 12 Mar 2025 at 16:11, Tender Wang <tndrwang(at)gmail(dot)com> wrote:
> >
> > I can find another same error in the below query:
> >
> > with t as (update part_abc set c = true where a = stable_one() +2
> returning a) insert into foo select a from t;
> >
>
> Interesting example. That passes in HEAD, but fails with the v1 patch
> because it is attempting to open a pruned result relation when it
> doesn't need to.
>
> Attached is a rough patch that attempts to solve these issues locally
> in ExecInitModifyTable(), by not allowing all result relations to be
> pruned for that node. That makes it easy to handle cases with multiple
> ModifyTable nodes.
>
> This also has the advantage that all these relations can continue to
> be pruned from the subplans of the ModifyTable nodes, making those
> scans more efficient, and it only keeps a pruned result relation if
> all other result relations have been pruned.
>
> It does mean that ExecGetRangeTableRelation() needs to allow pruned
> relations to be opened, if called from ExecInitResultRelation(). I
> think that's OK because the check for opening pruned relations still
> applies to scan relations.
>
> I also adjusted explain.c slightly, to avoid the dummy pruned result
> relation that we might now keep from appearing in the EXPLAIN output
> as a target relation. Allowing it to be shown looked a bit odd,
> because it's not really the target relation in any real sense.
>
> I also noticed a few Asserts in ExecInitModifyTable() that didn't
> appear to be doing what they were originally intended to do.
>

I tested and debugged the attached patch. I didn't find any other issue.

A comment in execPartition.h may need to be changed:
* partrel Partitioned table
Relation; obtained by
*
ExecGetRangeTableRelation(estate, rti), where

Because the func interface has changed, the above comments are better to be
changed "ExecGetRangeTableRelation(estate, rti, false)".

--
Thanks,
Tender Wang