Re: BUG #19484: Segmentation fault triggered by FDW

Amit-san,

On Wed, Jun 24, 2026 at 1:25 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> On Wed, Jun 24, 2026 at 11:23 AM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> > On Wed, Jun 24, 2026 at 10:43 AM Amit Langote <amitlangote09(at)gmail(dot)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.

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.

Best regards,
Etsuro Fujita