Re: BUG #19484: Segmentation fault triggered by FDW

Fujita-san,

On Wed, Jun 24, 2026 at 6:15 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> On Wed, Jun 24, 2026 at 1:25 PM Amit Langote <amitlangote09@gmail.com> wrote:
> > On Wed, Jun 24, 2026 at 11:23 AM Richard Guo <guofenglinux@gmail.com> wrote:
> > > On Wed, Jun 24, 2026 at 10:43 AM Amit Langote <amitlangote09@gmail.com> wrote:
> > > > If we’d rather avoid it, I have a no-field alternative for REL_18: show_modifytable_info() is the only reader of the re-indexed list, and it can recompute the mapping from node->resultRelations and node->fdwPrivLists, both plan-ordered and untouched by pruning.
> > >
> > > This sounds like a nice solution.  Since show_modifytable_info() is
> > > only used for EXPLAIN, I guess the recompute overhead on the
> > > re-indexed list should be fine.
> >
> > Thanks for chiming in, here is the patch to do so.
>
> Thanks for the patch!
>
> +           /*
> +            * node->fdwPrivLists is indexed by the original, pre-pruning
> +            * result relation order and is parallel to node->resultRelations.
> +            * Initial pruning may have dropped earlier relations, so the kept
> +            * index j need not match the original position; find this
> +            * relation's entry by its range table index instead.
> +            */
> +           forboth(lc1, node->resultRelations, lc2, node->fdwPrivLists)
> +           {
> +               if (lfirst_int(lc1) == (int) rti)
> +               {
> +                   fdw_private = (List *) lfirst(lc2);
> +                   break;
> +               }
> +           }
>
> I think it's good to skip this for efficiency, when there are no
> pruned result relations.

Thanks for the review. v2 attached implements your suggestion: it
indexes node->fdwPrivLists directly with j when no result relations
were pruned, and only falls back to matching by range table index when
pruning appears to have dropped some.

> Other than that the patch looks good to me.
>
> I didn't know pg_rewrite's use of ModifyTableState, which was
> different than I expected.  Sorry for that.

No need to apologize at all. Tom's point about it was new to me too.

I will push v2 to REL_18 tomorrow barring objections.

--
Thanks, Amit Langote