agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Re-index ModifyTable FDW arrays when pruning result relations 3+ messages / 2 participants [nested] [flat]
* pgsql: Re-index ModifyTable FDW arrays when pruning result relations @ 2026-06-23 23:59 Amit Langote <amitlan@postgresql.org> 0 siblings, 0 replies; 3+ messages in thread From: Amit Langote @ 2026-06-23 23:59 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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@qq.com> Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Author: Rafia Sabih <rafia.pghackers@gmail.com> Reviewed-by: Matheus Alcantara <matheusssilv97@gmail.com> Reviewed-by: Etsuro Fujita <etsuro.fujita@gmail.com> 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(-) ^ permalink raw reply [nested|flat] 3+ messages in thread
* pgsql: Re-index ModifyTable FDW arrays when pruning result relations @ 2026-06-24 00:00 Amit Langote <amitlan@postgresql.org> 0 siblings, 1 reply; 3+ messages in thread From: Amit Langote @ 2026-06-24 00:00 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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@qq.com> Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Author: Rafia Sabih <rafia.pghackers@gmail.com> Reviewed-by: Matheus Alcantara <matheusssilv97@gmail.com> Reviewed-by: Etsuro Fujita <etsuro.fujita@gmail.com> Discussion: https://postgr.es/m/19484-a3cb82c8cde3c8fa%40postgresql.org Backpatch-through: 18 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/b43f8aa4cb302c3f74fd1ed611e3548d4e03dce1 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(-) ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: pgsql: Re-index ModifyTable FDW arrays when pruning result relations @ 2026-06-24 01:08 Amit Langote <amitlangote09@gmail.com> parent: Amit Langote <amitlan@postgresql.org> 0 siblings, 0 replies; 3+ messages in thread From: Amit Langote @ 2026-06-24 01:08 UTC (permalink / raw) To: Amit Langote <amitlan@postgresql.org>; +Cc: pgsql-committers@lists.postgresql.org On Wed, Jun 24, 2026 at 9:00 Amit Langote <amitlan@postgresql.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@qq.com> > Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com> > Author: Rafia Sabih <rafia.pghackers@gmail.com> > Reviewed-by: Matheus Alcantara <matheusssilv97@gmail.com> > Reviewed-by: Etsuro Fujita <etsuro.fujita@gmail.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 > ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2026-06-24 01:08 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-06-23 23:59 pgsql: Re-index ModifyTable FDW arrays when pruning result relations Amit Langote <amitlan@postgresql.org> 2026-06-24 00:00 pgsql: Re-index ModifyTable FDW arrays when pruning result relations Amit Langote <amitlan@postgresql.org> 2026-06-24 01:08 ` Amit Langote <amitlangote09@gmail.com>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox