MIME-Version: 1.0
References: <19484-a3cb82c8cde3c8fa@postgresql.org>
 <CAJTYsWXY9C3B-7NZw72OKen2L2rZt=c-t6=kjTJzgj=ZaNPe8g@mail.gmail.com>
 <DIPI7GSQFV1C.20OALZACS6KLI@gmail.com>
 <CA+FpmFc10Dtnr9dr=xqK2cNYQ4-1VuOyvOT7-eqXPmiQJoyPew@mail.gmail.com>
 <DJ4M4TOUHLM0.B38DAVN79FPH@gmail.com>
 <CAJTYsWWUfgCZau2fvrZVruXmC+dyOx45L=TyaGzXdywsywDyHQ@mail.gmail.com>
 <DJ5BM93JVJ7C.MQC43GITCBOY@gmail.com>
 <CA+HiwqHVMY1a5E+6Ei369+RqQ8qKSSgon_C=3yBk-TPJDwZ2nQ@mail.gmail.com>
 <CA+HiwqHjUO0uXFZ2dECJiNime6B1FDL5+mJ=XN+1XgzkY=m9DA@mail.gmail.com>
 <CAPmGK16GNiwcnAxM3XU=ZTOP_8oiv7_FOUwo5hZp8b+qfv2L7g@mail.gmail.com>
 <CA+HiwqEVwEPSE4yMvuwVT5bb+ziMHLfqd_HuiQPAFAixNHbhrQ@mail.gmail.com>
 <CA+HiwqHO0Bbi6cyk4F+UGvZEV3NEo7o0YT3-Js7K7hvasoWBVw@mail.gmail.com>
 <CAPmGK16fALJqbyR1Oir7-TsN8k_yAR-JcOg5nWOUmDmivTmDtA@mail.gmail.com>
 <CAPmGK14Qh_Wb4GNPNkZ1o9=vTcMKShzPNSWa=wNf9vJpg8qT+Q@mail.gmail.com>
 <CA+HiwqHRDsYDqJ-7f5P_QpJo=U1BYzMnfDnNOr6Vx3Rw36O0iQ@mail.gmail.com>
 <CAPmGK15nR_pePb9QAMViq+AGuWeJSqPnLTJVLsr96aU2TFmcmw@mail.gmail.com>
 <CA+HiwqFT0VDOCAdN1bcVZTOF0oBbR4kzLF-OwEcgPOf01me-Kw@mail.gmail.com>
 <CAPmGK15nx4a_QkTcbD2BwsDuDPtbS25Pzmq_sc-xM4EitoHaxw@mail.gmail.com>
 <CA+HiwqHTsZmceNHxVfmD0VVN-F1eMSuVQYVDWfsz3OSe+qoO7A@mail.gmail.com>
 <CA+HiwqEhe7-v5Q0-oOoW3RaO4voYcGK-JfinbYEWXwutDGSOtQ@mail.gmail.com>
 <CAMbWs4-hBR6H3AEv1LkcnRt04Q4zgVVUeOqmA6-W=DSP65s3Xw@mail.gmail.com>
 <CA+HiwqEbqW_957S9UAEoZJ5aYyBF_Bp+ON+6thQNCySxSwv+Fg@mail.gmail.com>
 <CAPmGK14CFGgCSCor1DHe6GVVQpjj+zDq755K5_vgc32U2+OGYQ@mail.gmail.com>
 <CA+HiwqFd61sXgUWijKg8DfRQDtwYEGSdxuEPDb8rq22rxzxN_g@mail.gmail.com>
 <CAPmGK15do2D1YJFR2VST6+8BnADyZbiiY1hk+HhMGgFyBkE70Q@mail.gmail.com>
 <CA+HiwqEr9AQoG=ySqC9nVJ7n9F52xPYGEb-r2xCW5ut0QhzauA@mail.gmail.com>
In-Reply-To: 
 <CA+HiwqEr9AQoG=ySqC9nVJ7n9F52xPYGEb-r2xCW5ut0QhzauA@mail.gmail.com>
From: Etsuro Fujita <etsuro.fujita@gmail.com>
Date: Thu, 25 Jun 2026 15:15:22 +0900
Message-ID: 
 <CAPmGK17342yvbaECJV22-zBYZcG7vS0kEm74iDOMmC2J96Eq=w@mail.gmail.com>
Subject: Re: BUG #19484: Segmentation fault triggered by FDW
To: Amit Langote <amitlangote09@gmail.com>
Cc: Richard Guo <guofenglinux@gmail.com>,
 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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAPmGK17342yvbaECJV22-zBYZcG7vS0kEm74iDOMmC2J96Eq%3Dw%40mail.gmail.com>
Precedence: bulk

Amit-san,

On Thu, Jun 25, 2026 at 8:24=E2=80=AFAM Amit Langote <amitlangote09@gmail.c=
om> wrote:
> On Thu, Jun 25, 2026 at 2:02=E2=80=AFAM Etsuro Fujita <etsuro.fujita@gmai=
l.com> wrote:
> > This might be nitpicking, but:
> >
> > +           if (list_length(node->resultRelations) =3D=3D mtstate->mt_n=
rels)
> > +               fdw_private =3D (List *) list_nth(node->fdwPrivLists, j=
);
> > +           else
> > +           {
> > +               Index       rti =3D resultRelInfo->ri_RangeTableIndex;
> > +               ListCell   *lc1;
> > +               ListCell   *lc2;
> > +
> > +               fdw_private =3D NIL;
> > +               forboth(lc1, node->resultRelations, lc2, node->fdwPrivL=
ists)
> > +               {
> > +                   if (lfirst_int(lc1) =3D=3D (int) rti)
> > +                   {
> > +                       fdw_private =3D (List *) lfirst(lc2);
> > +                       break;
> > +                   }
> > +               }
> > +           }
> >
> > I'd put the if-test outside of the outer loop to save cycles.
>
> Right, it's loop-invariant. v3 attached computes a boolean
> (nopruning), like labeltargets, once before the loop and uses it
> inside.
>
> > Other than that v2 looks good to me.
> >
> > (The forboth loop actually causes an n-squared calculation, but it's
> > done only when pruning occurs, in which case the number of remaining
> > result relations would be reduced, so that wouldn't be a problem.)
>
> Right, though strictly the inner forboth scans node->resultRelations,
> which pruning leaves at its original length, so it's the original
> relation count that bounds the scan rather than the reduced one.
> Either way it's EXPLAIN-only with small counts, so it's not a concern.

That's right.

The v3 patch looks good to me.  Thanks for updating the patch!

Best regards,
Etsuro Fujita