Thread

Re: BUG #19111: Using EXPLAIN ANALYZE with MERGE causes failed assert

Dean Rasheed <dean.a.rasheed@gmail.com> — 2025-11-13T15:32:04Z

On Thu, 13 Nov 2025 at 12:18, PG Bug reporting form
<noreply@postgresql.org> wrote:
>
> On PostgreSQL 17+ if you do the following:
> ...
> Then the backend for the second psql crashes. With asserts turned on.

Thanks for the report.

What's happening here is that the MERGE in the second query has both
NOT MATCHED BY SOURCE and NOT MATCHED BY TARGET actions, so it does a
full join between the two tables. Initially there is a single matched
row, but the concurrent update turns that into a not matched pair of
rows and both actions are executed. So the ModifyTable node processes
it as 2 rows, whereas its parent node only outputs 1 row, which is
something the explain code doesn't like (because it computes the
difference, interpreting that as the number of rows skipped).

A possible solution would be something like the attached. It feels a
little ugly, but I don't see any other easy fix.

It's only a rough patch (it should have an isolation test case), but
it fixes the problem by causing the parent (full join) node to report
that it returned 2 rows, which it didn't really, but it would have
done, if the other update had happened before the MERGE, rather than
concurrently.

(Of course we could just drop that Assert, and it wouldn't cause any
harm, but it seems preferable to try to get the row counts right.)

Regards,
Dean