Horton
Menu

Re: BUG #18830: ExecInitMerge Segfault on MERGE

Dean Rasheed <dean.a.rasheed@gmail.com>

View thread
From: Dean Rasheed <dean.a.rasheed@gmail.com>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Tender Wang <tndrwang@gmail.com>, David Rowley <dgrowleyml@gmail.com>, pgsql-bugs@lists.postgresql.org, tharakan@gmail.com
Date: 2025-03-13T14:42:10Z
Lists: pgsql-bugs 
On Thu, 13 Mar 2025 at 12:44, Amit Langote <amitlangote09@gmail.com> wrote:
>
> One thing I'd like to avoid is taking any locks during ExecInitNode(),
> including in functions like ExecGetRangeTableRelation(). Doing so
> would require checking whether the CachedPlan is still valid and
> handling invalidation if it isn't -- see commit 525392d5727f for
> background.
>

Yes, I wondered about that. I saw that earlier commit, and the notes
in the executor README, but I still don't quite understand.
Specifically, how is locking this pruned leaf partition in
ExecInitModifyTable() different from locking any other pruned leaf
partition later in the INSERT path? (For example, as part of an UPDATE
that moves a tuple from an unpruned partition to a pruned one.)

Regards,
Dean

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Ensure first ModifyTable rel initialized if all are pruned

  2. Don't lock partitions pruned by initial pruning

  3. Fix an oversight in cbc127917 to handle MERGE correctly

  4. Remove some unnecessary fields from Plan trees.