pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix Assert failure in EXPLAIN ANALYZE MERGE with a concurrent up 3+ messages / 1 participants [nested] [flat]
* pgsql: Fix Assert failure in EXPLAIN ANALYZE MERGE with a concurrent up @ 2025-11-16 22:17 Dean Rasheed <dean.a.rasheed@gmail.com> 0 siblings, 0 replies; 3+ messages in thread From: Dean Rasheed @ 2025-11-16 22:17 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix Assert failure in EXPLAIN ANALYZE MERGE with a concurrent update. When instrumenting a MERGE command containing both WHEN NOT MATCHED BY SOURCE and WHEN NOT MATCHED BY TARGET actions using EXPLAIN ANALYZE, a concurrent update of the target relation could lead to an Assert failure in show_modifytable_info(). In a non-assert build, this would lead to an incorrect value for "skipped" tuples in the EXPLAIN output, rather than a crash. This could happen if the concurrent update caused a matched row to no longer match, in which case ExecMerge() treats the single originally matched row as a pair of not matched rows, and potentially executes 2 not-matched actions for the single source row. This could then lead to a state where the number of rows processed by the ModifyTable node exceeds the number of rows produced by its source node, causing "skipped_path" in show_modifytable_info() to be negative, triggering the Assert. Fix this in ExecMergeMatched() by incrementing the instrumentation tuple count on the source node whenever a concurrent update of this kind is detected, if both kinds of merge actions exist, so that the number of source rows matches the number of actions potentially executed, and the "skipped" tuple count is correct. Back-patch to v17, where support for WHEN NOT MATCHED BY SOURCE actions was introduced. Bug: #19111 Reported-by: Dilip Kumar <dilipbalaut@gmail.com> Author: Dean Rasheed <dean.a.rasheed@gmail.com> Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com> Discussion: https://postgr.es/m/19111-5b06624513d301b3@postgresql.org Backpatch-through: 17 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d6c415c4b4b19b9fa39151c5d1a804683b83535d Modified Files -------------- src/backend/executor/nodeModifyTable.c | 21 ++++ src/test/isolation/expected/merge-update.out | 146 +++++++++++++++++++++++++++ src/test/isolation/specs/merge-update.spec | 50 +++++++++ 3 files changed, 217 insertions(+) ^ permalink raw reply [nested|flat] 3+ messages in thread
* pgsql: Fix Assert failure in EXPLAIN ANALYZE MERGE with a concurrent up @ 2025-11-16 22:17 Dean Rasheed <dean.a.rasheed@gmail.com> 0 siblings, 0 replies; 3+ messages in thread From: Dean Rasheed @ 2025-11-16 22:17 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix Assert failure in EXPLAIN ANALYZE MERGE with a concurrent update. When instrumenting a MERGE command containing both WHEN NOT MATCHED BY SOURCE and WHEN NOT MATCHED BY TARGET actions using EXPLAIN ANALYZE, a concurrent update of the target relation could lead to an Assert failure in show_modifytable_info(). In a non-assert build, this would lead to an incorrect value for "skipped" tuples in the EXPLAIN output, rather than a crash. This could happen if the concurrent update caused a matched row to no longer match, in which case ExecMerge() treats the single originally matched row as a pair of not matched rows, and potentially executes 2 not-matched actions for the single source row. This could then lead to a state where the number of rows processed by the ModifyTable node exceeds the number of rows produced by its source node, causing "skipped_path" in show_modifytable_info() to be negative, triggering the Assert. Fix this in ExecMergeMatched() by incrementing the instrumentation tuple count on the source node whenever a concurrent update of this kind is detected, if both kinds of merge actions exist, so that the number of source rows matches the number of actions potentially executed, and the "skipped" tuple count is correct. Back-patch to v17, where support for WHEN NOT MATCHED BY SOURCE actions was introduced. Bug: #19111 Reported-by: Dilip Kumar <dilipbalaut@gmail.com> Author: Dean Rasheed <dean.a.rasheed@gmail.com> Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com> Discussion: https://postgr.es/m/19111-5b06624513d301b3@postgresql.org Backpatch-through: 17 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/1b92fe7bb9d8b8977bf7e48912b12f97f128ec1d Modified Files -------------- src/backend/executor/nodeModifyTable.c | 21 ++++ src/test/isolation/expected/merge-update.out | 146 +++++++++++++++++++++++++++ src/test/isolation/specs/merge-update.spec | 50 +++++++++ 3 files changed, 217 insertions(+) ^ permalink raw reply [nested|flat] 3+ messages in thread
* pgsql: Fix Assert failure in EXPLAIN ANALYZE MERGE with a concurrent up @ 2025-11-16 22:17 Dean Rasheed <dean.a.rasheed@gmail.com> 0 siblings, 0 replies; 3+ messages in thread From: Dean Rasheed @ 2025-11-16 22:17 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix Assert failure in EXPLAIN ANALYZE MERGE with a concurrent update. When instrumenting a MERGE command containing both WHEN NOT MATCHED BY SOURCE and WHEN NOT MATCHED BY TARGET actions using EXPLAIN ANALYZE, a concurrent update of the target relation could lead to an Assert failure in show_modifytable_info(). In a non-assert build, this would lead to an incorrect value for "skipped" tuples in the EXPLAIN output, rather than a crash. This could happen if the concurrent update caused a matched row to no longer match, in which case ExecMerge() treats the single originally matched row as a pair of not matched rows, and potentially executes 2 not-matched actions for the single source row. This could then lead to a state where the number of rows processed by the ModifyTable node exceeds the number of rows produced by its source node, causing "skipped_path" in show_modifytable_info() to be negative, triggering the Assert. Fix this in ExecMergeMatched() by incrementing the instrumentation tuple count on the source node whenever a concurrent update of this kind is detected, if both kinds of merge actions exist, so that the number of source rows matches the number of actions potentially executed, and the "skipped" tuple count is correct. Back-patch to v17, where support for WHEN NOT MATCHED BY SOURCE actions was introduced. Bug: #19111 Reported-by: Dilip Kumar <dilipbalaut@gmail.com> Author: Dean Rasheed <dean.a.rasheed@gmail.com> Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com> Discussion: https://postgr.es/m/19111-5b06624513d301b3@postgresql.org Backpatch-through: 17 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/5749d95d47941d1240e68ad0f4e0eba0e569aeb8 Modified Files -------------- src/backend/executor/nodeModifyTable.c | 21 ++++ src/test/isolation/expected/merge-update.out | 146 +++++++++++++++++++++++++++ src/test/isolation/specs/merge-update.spec | 50 +++++++++ 3 files changed, 217 insertions(+) ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2025-11-16 22:17 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-11-16 22:17 pgsql: Fix Assert failure in EXPLAIN ANALYZE MERGE with a concurrent up Dean Rasheed <dean.a.rasheed@gmail.com> 2025-11-16 22:17 pgsql: Fix Assert failure in EXPLAIN ANALYZE MERGE with a concurrent up Dean Rasheed <dean.a.rasheed@gmail.com> 2025-11-16 22:17 pgsql: Fix Assert failure in EXPLAIN ANALYZE MERGE with a concurrent up Dean Rasheed <dean.a.rasheed@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox