Re: BUG #19484: Segmentation fault triggered by FDW

Amit-san,

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.

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