Re: BUG #18830: ExecInitMerge Segfault on MERGE

On Tue, Mar 4, 2025 at 4:36 PM Tender Wang <tndrwang@gmail.com> wrote:
> Amit Langote <amitlangote09@gmail.com> 于2025年3月4日周二 18:10写道：
>> On Tue, Mar 4, 2025 at 3:16 PM Tender Wang <tndrwang@gmail.com> wrote:
>> > David Rowley <dgrowleyml@gmail.com> 于2025年3月4日周二 17:30写道：
>> >> There are a couple of ways I can see to fix this, 1) would be to move
>> >> the ExecAssignExprContext() above the "if (mergeActionLists == NIL)"
>> >> in ExecInitMerge(), or 2) add code to return NULL in
>> >> ExecMergeNotMatched() if actionStates is NULL.
>> >>
>> >> I think maybe #1 is the better option as #2 adds additional code that
>> >> executes on every ExecMergeNotMatched() call.  The patch does #1. We
>> >> should probably add your test case too.
>> >>
>> > Hmm,  apply your patch, I get different results when set enable_partition_pruning = off, seeing below:
>> > postgres=# merge into part_abc_view pt
>> > using (select stable_one() + 2 as pid) as q join part_abc_1 pt1 on (true)
>> > on pt.a = stable_one() +2
>> > when not matched then insert values(1, 'd', false);
>> > MERGE 0
>> > postgres=# set enable_partition_pruning = off;
>> > SET
>> > postgres=# merge into part_abc_view pt
>> > using (select stable_one() + 2 as pid) as q join part_abc_1 pt1 on (true)
>> > on pt.a = stable_one() +2
>> > when not matched then insert values(1, 'd', false);
>> > MERGE 1
>>
>> Hmm, interesting.  Can you share the full test case?
>>
>> What's the behavior on v17 and older?  Just want to be sure if we're
>> looking at another bug in the code committed in v18.
>
>
> Because all partitions are pruned, so   bms_is_member(rti,
> estate->es_unpruned_relids) is false, then mergeActionLists is empty.
> Even though we initialize  econtext  to not null, but in ExecMergeNotMatched(),
> because actionStates list is empty, so no merge operation happens.
> actionStates is empty due to empty mergeActionLists.

Yes, I get that.  What I am wondering about is whether the case you
presented where disabling partition pruning gives a different result
for the same query has anything to do with this particular bug that's
causing the crash Robins reported.  If there's a separate bug, we have
to check if it is present in v17 and older.

--
Thanks, Amit Langote