Re: pgsql: Re-index ModifyTable FDW arrays when pruning result relations

On Wed, Jun 24, 2026 at 9:00 Amit Langote <amitlan(at)postgresql(dot)org> wrote:

> Re-index ModifyTable FDW arrays when pruning result relations
>
> ExecInitModifyTable() rebuilds the per-result-relation lists after
> dropping result relations removed by initial runtime pruning. The
> re-indexing was done for withCheckOptionLists, returningLists,
> updateColnosLists, mergeActionLists and mergeJoinConditions, but
> fdwPrivLists and fdwDirectModifyPlans were missed. As a result, a
> kept foreign result relation could be handed the wrong fdw_private,
> or ri_usesFdwDirectModify could be set from the wrong plan index,
> leading to wrong behavior or a crash in BeginForeignModify() and in
> the direct-modify path.
>
> show_modifytable_info() had the same problem: it indexed the
> plan-ordered node->fdwPrivLists with the post-pruning executor
> position, so once initial pruning removed a result relation it
> could read a different relation's fdw_private (often a NIL entry),
> producing wrong EXPLAIN output or a crash.
>
> Fix by re-indexing fdwPrivLists and fdwDirectModifyPlans alongside
> the other lists, saving the re-indexed private lists in
> ModifyTableState.mt_fdwPrivLists and reading from there in both
> nodeModifyTable.c and explain.c.
>
> Reported-by: Chi Zhang <798604270(at)qq(dot)com>
> Author: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
> Author: Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>
> Reviewed-by: Matheus Alcantara <matheusssilv97(at)gmail(dot)com>
> Reviewed-by: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
> Discussion: https://postgr.es/m/19484-a3cb82c8cde3c8fa%40postgresql.org
> Backpatch-through: 18

Oops, looks like I missed the Bug # in the commit message. It’s 19484 fwiw.

- Amit

>