Re: BUG #19484: Segmentation fault triggered by FDW

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
Cc: Matheus Alcantara <matheusssilv97(at)gmail(dot)com>, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>, Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>, 798604270(at)qq(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, Amit Langote <amitlan(at)postgresql(dot)org>
Subject: Re: BUG #19484: Segmentation fault triggered by FDW
Date: 2026-06-24 00:00:59
Message-ID: CA+HiwqHTsZmceNHxVfmD0VVN-F1eMSuVQYVDWfsz3OSe+qoO7A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Tue, Jun 23, 2026 at 5:27 PM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> wrote:
> On Mon, Jun 22, 2026 at 5:28 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> > On Fri, Jun 19, 2026 at 8:59 PM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Amit Langote 2026-06-24 01:43:32 Re: BUG #19484: Segmentation fault triggered by FDW
Previous Message Hüseyin Demir 2026-06-23 08:32:34 Re: BUG #19483: pg_upgrade fails with orphan records in pg_init_priv catalog table