Re: BUG #19484: Segmentation fault triggered by FDW

Поиск
Список
Период
Сортировка
Искать
От
Etsuro Fujita
Тема
Re: BUG #19484: Segmentation fault triggered by FDW
Дата
в 11:27:39
Msg-id
CAPmGK15nx4a_QkTcbD2BwsDuDPtbS25Pzmq_sc-xM4EitoHaxw@mail.gmail.com
Ответ на
Список
Дерево обсуждения
Re: Add vacuum_delay_point() to GiST empty-page deletion pass Paul Kim <mok03127@gmail.com>
Amit-san,

On Mon, Jun 22, 2026 at 5:28 PM Amit Langote  wrote:
> On Fri, Jun 19, 2026 at 8:59 PM Etsuro Fujita  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.

Best regards,
Etsuro Fujita


В списке pgsql-bugs по дате отправления
FAQ