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 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/1ef917e3a61a26a264fe65012d951ac36aa03732 Modified Files -------------- contrib/postgres_fdw/expected/postgres_fdw.out | 64 ++++++++++++++++++++++++++ contrib/postgres_fdw/sql/postgres_fdw.sql | 34 ++++++++++++++ src/backend/commands/explain.c | 2 +- src/backend/executor/nodeModifyTable.c | 22 ++++++++- src/include/nodes/execnodes.h | 8 ++-- 5 files changed, 124 insertions(+), 6 deletions(-)
