Re: MERGE issues around inheritance - Mailing list pgsql-hackers

From Tender Wang
Subject Re: MERGE issues around inheritance
Date
Msg-id CAHewXNmU-GyH7bMt1NszQy28qjS_3h6ki4nZR+c6d7-Hf-9F8g@mail.gmail.com
Whole thread Raw
In response to Re: MERGE issues around inheritance  (jian he <jian.universality@gmail.com>)
Responses Re: MERGE issues around inheritance
List pgsql-hackers


jian he <jian.universality@gmail.com> 于2025年5月26日周一 17:30写道:
On Mon, May 26, 2025 at 4:11 AM Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>
> On Sun, 25 May 2025 at 13:41, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
> >
>
> 2. ExecInitModifyTable() does not initialize the WCO lists or
> RETURNING list for rootResultRelInfo, so those never get executed.
>
> As it happens, it is possible to construct cases where (1) causes a
> crash, even without WCO's or a RETURNING list (see the first test case
> in the attached patch), so this bug goes all the way back to v15,
> where MERGE was introduced.
>
> So I think we need to do something like the attached.
>
> There is perhaps scope to reduce the code duplication between this and
> ExecInitPartitionInfo(), but that'd likely make the patch bigger, so I
> think it's best to leave that for now.

+ Relation rootRelation = rootRelInfo->ri_RelationDesc;
+ Relation firstResultRel = mtstate->resultRelInfo[0].ri_RelationDesc;
+ int firstVarno = mtstate->resultRelInfo[0].ri_RangeTableIndex;

firstResultRel may equal (==) to rootRelation,
in that case, we don't need to call map_variable_attnos?

+       if (rootRelInfo != mtstate->resultRelInfo &&
+               rootRelInfo->ri_RelationDesc->rd_rel->relkind != RELKIND_PARTITIONED_TABLE &&
+               (mtstate->mt_merge_subcommands & MERGE_INSERT) != 0)

Above if already does the check.


--
Thanks,
Tender Wang

pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: MERGE issues around inheritance
Next
From: "Vitaly Davydov"
Date:
Subject: Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly