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 →
-
Avoid ABI break in ModifyTableState from the FDW pruning fix
- bba4e095d250 18 (unreleased) landed
-
Re-index ModifyTable FDW arrays when pruning result relations
- b43f8aa4cb30 19 (unreleased) landed
- 1ef917e3a61a 18 (unreleased) landed
-
Fix universal builds on MacOS
- 901ed9b352b4 19 (unreleased) cited
-
Track unpruned relids to avoid processing pruned relations
- cbc127917e04 18.0 cited