From: | Tender Wang <tndrwang(at)gmail(dot)com> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Subject: | Re: MERGE issues around inheritance |
Date: | 2025-05-25 12:05:59 |
Message-ID: | CAHewXNn_W6v45GC5ce3qWF+KtOPR1i6xYeNwnw9G-_HSWitaCA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tender Wang <tndrwang(at)gmail(dot)com> 于2025年5月25日周日 19:17写道:
>
>
> Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> 于2025年5月24日周六 17:11写道:
>
>> On 2025-May-21, Andres Freund wrote:
>>
>> > Hi,
>> >
>> > In [1] I added some verification to projection building, to check if the
>> > tupleslot passed to ExecBuildProjectionInfo() is compatible with the
>> target
>> > list. One query in merge.sql [2] got flagged.
>> >
>> > Trying to debug that issue, I found another problem. This leaves us
>> with:
>> >
>> > 1) w/ inheritance INSERTed rows are not returned by RETURNING. This
>> seems to
>> > just generally not work with MERGE
>>
>> Hmm, curious. One thing to observe is that the original source tuple is
>> in the child table, but the tuple inserted by MERGE ends up in the
>> parent table. I'm guessing that the code gets confused as to the
>> relation that the tuple in the returned slot comes from, and that
>> somehow makes it somehow not "see" the tuple to process for RETURNING?
>> I dunno. CC'ing Dean, who is more familiar with this code than I am.
>>
>
> In ExecMergeNotMatched(), we passed the mtstate->rootResultRelInfo to
> ExecInsert().
> In this case, the ri_projectReturning of mtstate->rootResultRelInfo is
> NULL, in ExecInsert(),
> the "if (resultRelInfo->ri_projectReturning)" branch will not run, so
> inheritance INSERTed rows are not returned by RETURNING.
>
> The mtstate->rootResultRelInfo assigned in ExecInitModifyTable() is only
> here:
> if (node->rootRelation > 0)
> {
> Assert(bms_is_member(node->rootRelation, estate->es_unpruned_relids));
> mtstate->rootResultRelInfo = makeNode(ResultRelInfo);
> ExecInitResultRelation(estate, mtstate->rootResultRelInfo,
> node->rootRelation);
> }
> The ri_projectReturning is not assigned.
>
> I try to pass resultRelInfo to ExecInsert, the inherited INSERTed rows are
> returned by RETURNING.
> But some test cases in regression failed.
>
For a partitioned table, we must pass rootResultRelInfo to ExecInsert(). I
added the check before calling ExecInsert()
If it is a partitioned table, we continue to pass rootResultRelInfo.
Otherwise, we pass resultRelInfo.
Please see the attached diff file. The patch passed all regression test
cases.
--
Thanks,
Tender Wang
Attachment | Content-Type | Size |
---|---|---|
merge_inh.diff | text/plain | 1.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2025-05-25 12:41:40 | Re: MERGE issues around inheritance |
Previous Message | Dilip Kumar | 2025-05-25 11:36:49 | Re: Hash table scans outside transactions |