Re: wrong results: merge when not matched by source

On Fri, 18 Sept 2026, 13:52 Tender Wang, <tndrwang(at)gmail(dot)com> wrote:

> Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> 于2026年9月18日周五 20:22写道：
> >
> > On Fri, 18 Sept 2026, 12:03 Dean Rasheed, <dean(dot)a(dot)rasheed(at)gmail(dot)com>
> wrote:
> >>
> >>
> >> That fix looks good to me. Nice and simple.
> >
> >
> > Actually, the last part of the new comment is wrong/unnecessary. If it
> changes matched from true to false, retrying, it will have locked the
> target tuple, and it can't be concurrently deleted when it retries. It
> never retries more than once. So the comment can be simplified a bit.
> >
>
> Thanks for confirming.
>
> I also noticed the following part of the comment at the beginning of
> `ExecMerge()`:
>
> ...
> If the target tuple gets deleted or a concurrent update causes the join
> quals to fail, it returns a matched status of false and we call
> ExecMergeNotMatched().
> ...
>
> With this change, perhaps this part of the comment should also be
> adjusted to distinguish an original `WHEN MATCHED` case from an
> original `WHEN NOT MATCHED BY SOURCE` case.
>
> For the former, a concurrent delete leaves the source tuple to be
> processed by `WHEN NOT MATCHED [BY TARGET]` actions, whereas for the
> latter, neither a source tuple nor a target tuple remains, so there is
> no further action to execute.
>
> Do you think it's worth updating this comment as part of the patch?
>

Sure. I'm AFK at the moment, so if you want to have a crack at that, I'll
take a look when I get back.

Regards,
Dean

>