Re: BUG #19484: Segmentation fault triggered by FDW

amit <amitlangote09@gmail.com>

From: Amit Langote <amitlangote09@gmail.com>
To: Etsuro Fujita <etsuro.fujita@gmail.com>
Cc: Matheus Alcantara <matheusssilv97@gmail.com>, Ayush Tiwari <ayushtiwari.slg01@gmail.com>, Rafia Sabih <rafia.pghackers@gmail.com>, 798604270@qq.com, pgsql-bugs@lists.postgresql.org, Amit Langote <amitlan@postgresql.org>
Date: 2026-06-24T00:00:59Z
Lists: pgsql-bugs
On Tue, Jun 23, 2026 at 5:27 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> On Mon, Jun 22, 2026 at 5:28 PM Amit Langote <amitlangote09@gmail.com> wrote:
> > On Fri, Jun 19, 2026 at 8:59 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
>
> > > +-- Runtime pruning of result relations must keep ModifyTable's per-relation
> > > +-- FDW arrays (fdwPrivLists, fdwDirectModifyPlans) aligned with the kept
> > > +-- resultRelations.  Otherwise BeginForeignModify() reads the wrong
> > > +-- fdw_private and segfaults.
> > >
> > > This comment isn't 100% correct, because this issue happens with
> > > DirectModify as well.  I think we could expand the comment to mention
> > > that as well, but the comment is already too much/detailed IMO; I
> > > don't think we add such a comment for a test case, so how about
> > > simplifying the comment like this: "Test that direct modify and
> > > foreign modify work with runtime pruning of result relations (bug
> > > #19484)"
> >
> > I agree that the details shouldn't leak into test code and have been
> > trying to follow that principle.  Also, bug numbers shouldn't be
> > mentioned because one can always use `git blame` to find them.
> > However, since different committers have different styles, I'm fine
> > with it; kept in the attached updated patch.
>
> Thanks!
>
> > > @@ -1446,6 +1446,12 @@ typedef struct ModifyTableState
> > >     int         mt_nrels;       /* number of entries in resultRelInfo[] */
> > >     ResultRelInfo *resultRelInfo;   /* info about target relation(s) */
> > >
> > > +   /*
> > > +    * Re-indexed fdw private data lists, aligned with resultRelInfo[] after
> > > +    * pruning
> > > +    */
> > > +   List       *mt_fdwPrivLists;
> > >
> > > For v18, I think we should put this at the end of the ModifyTableState
> > > struct, to avoid ABI breakage.
> >
> > Good point on ABI. Rather than placing it differently per branch, how
> > about putting mt_fdwPrivLists at the end of the struct alongside
> > mt_updateColnosLists/mt_mergeActionLists/mt_mergeJoinConditions, which
> > are the same kind of unpruned-filtered lists? That keeps it ABI-safe
> > and lets master and 18 share an identical change. I'd fold it into
> > their existing comment too.
>
> That's a good idea!  So +1
>
> > Updated patch attached.
>
> LGTM.

Pushed, thanks for checking.


--
Thanks, Amit Langote



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Avoid ABI break in ModifyTableState from the FDW pruning fix

  2. Re-index ModifyTable FDW arrays when pruning result relations

  3. Fix universal builds on MacOS

  4. Track unpruned relids to avoid processing pruned relations