Re: Fix bug of UPDATE/DELETE FOR PORTION OF with inheritance tables

From: Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>
To: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fix bug of UPDATE/DELETE FOR PORTION OF with inheritance tables
Date: 2026-05-26 16:14:04
Message-ID: CA+renyVNmXityjqZNdKhG2SGkfKFM1dT72PTbkyQ5K6L9m9NuQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 25, 2026 at 11:55 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>
> Now v2 mixes two separate changes:
>
> 1) Adding ExecInitForPortionOf() to address the UPDATE OF trigger issue
> 2) Fixing the inheritance/leftover bug originally reported in this thread
>
> I’d prefer not to combine these in a single patch. Could you please split out the refactoring that adds ExecInitForPortionOf() into a separate patch, with tests showing that the UPDATE OF trigger issue is fixed? Then I can rework my inheritance/leftover fix on top of that.

Thanks for taking a look! I agree about keeping the fixes separate.
UPDATE OF triggers are fixed by the patch on the other thread (with
tests). Since we now include the application-time column in
updatedCols, there is nothing else to do there.

I thought the ExecInitForPortionOf refactoring was still nice to keep,
and it seemed to fit better here. (I should have updated the commit
message not to mention UPDATE OF though.)

But thinking about it this morning, I realized: the planner already
prunes partitions before we get here. Lazily initializing the structs
is trying too hard. Is there some scenario where that actually saves
work? If not, we could just set up all the structs in
ExecInitModifyTable. That's what I was doing in an older version of
the original patch. And then the refactor with ExecInitForPortionOf
seems unnecessary. I'll send a patch with those changes, unless you
have objections. (Probably two separate patches: one to remove lazy
initialization, another to actually fix traditional inheritance.) If
you disagree, please let me know.

Yours,

--
Paul ~{:-)
pj(at)illuminatedcomputing(dot)com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2026-05-26 16:40:19 Re: Bound memory usage during manual slot sync retries
Previous Message Nathan Bossart 2026-05-26 16:05:47 future of PQfn()