diff options
| author | Dean Rasheed | 2025-11-16 22:14:06 +0000 |
|---|---|---|
| committer | Dean Rasheed | 2025-11-16 22:14:06 +0000 |
| commit | 1b92fe7bb9d8b8977bf7e48912b12f97f128ec1d (patch) | |
| tree | 85181375a3f6aac6cf94129fceac8cd6a7ede840 /src/backend/commands/publicationcmds.c | |
| parent | 2b54a1abdbb09a4b170bca82726dabe7b2d6555b (diff) | |
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 <[email protected]>
Author: Dean Rasheed <[email protected]>
Reviewed-by: Dilip Kumar <[email protected]>
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 17
Diffstat (limited to 'src/backend/commands/publicationcmds.c')
0 files changed, 0 insertions, 0 deletions
