On Wed, Jun 24, 2026 at 9:00 Amit Langote <[email protected]> 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 <[email protected]> > Author: Ayush Tiwari <[email protected]> > Author: Rafia Sabih <[email protected]> > Reviewed-by: Matheus Alcantara <[email protected]> > Reviewed-by: Etsuro Fujita <[email protected]> > 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 >
