Re: wrong results: merge when not matched by source

Jeff Davis <pgsql(at)j-davis(dot)com> 于2026年9月18日周五 03:18写道：
>
> -- Expected: only UPDATE of key=1; table is {(1, src)}.
> -- Actual: also INSERT of (NULL, NULL).

I think the problem is that the TM_Deleted case in
ExecMergeMatched() unconditionally sets *matched to false.

This is correct when the candidate row was originally a MATCHED row:
the source row still exists after the target row is concurrently
deleted, so it should be processed by the NOT MATCHED BY TARGET
actions.

However, it is not correct when processing an original NOT MATCHED BY
SOURCE row. In that case, the source row was already absent, and after
the concurrent deletion of the target row, there is no candidate row
left to process. Setting *matched to false causes ExecMerge() to
call ExecMergeNotMatched(), which executes the NOT MATCHED BY TARGET
INSERT using the null source side of the original join row.

A tentative fix is to set *matched to false only if the current
action is a MATCHED action, as in the attached patch.

There is another TM_Deleted case below, reached while handling
TM_Updated and following the update chain:
...
case TM_Deleted:
*matched = false;
goto out;
...

I think that case may need similar treatment. The existing
was_matched variable could perhaps be used there:
...
if (was_matched)
*matched = false;
...
I have left that case unchanged for now because I would like to
confirm whether the same state distinction applies to all paths
through that code.

The attached patch is intended to show the proposed fix and does not
yet include a regression test.

--
Thanks,
Tender Wang