Re: Fix RETURNING side effects for FOR PORTION OF leftover rows

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>
Subject: Re: Fix RETURNING side effects for FOR PORTION OF leftover rows
Date: 2026-07-20 13:17:08
Message-ID: 594C0D8F-758C-4E31-8DCE-30CBE1248090@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Jul 20, 2026, at 16:56, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
>
> On Thu, 16 Jul 2026 at 07:20, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>
>> To fix the problem, since leftover rows are inserted by calling ExecInsert(), and ExecInsert() is a local static function, I think a simple and safe solution is to add a new parameter to ExecInsert() to indicate whether to process RETURNING for this insert. Then UPDATE/DELETE FOR PORTION OF can bypass RETURNING processing for leftover rows.
>
> I don't particularly like adding another argument to ExecInsert(). I
> think it can work out from its existing arguments whether it's part of
> a FOR PORTION OF query (by looking at mtstate).
>

Okay. We cannot simply check node->forPortionOf to bypass RETURNING processing, because an FPO update on a partitioned table may move a row to a different partition. In that case, ExecInsert() is also called to insert the row into the new partition.

However, in that case, mtstate->operation is still CMD_UPDATE, while for leftover rows, mtstate->operation is temporarily changed to CMD_INSERT. So we can check both node->forPortionOf and mtstate->operation.

PFA v2 with the new implementation. I tried to run check-world and it passed.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

Attachment Content-Type Size
v2-0001-Avoid-RETURNING-side-effects-for-FOR-PORTION-OF-l.patch application/octet-stream 7.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message ZizhuanLiu X-MAN 2026-07-20 13:24:19 Re: COMMENTS are not being copied in CREATE TABLE LIKE
Previous Message Robert Haas 2026-07-20 13:16:13 Re: log_postmaster_stats