Re: BUG #19111: Using EXPLAIN ANALYZE with MERGE causes failed assert
| От | Dean Rasheed |
|---|---|
| Тема | Re: BUG #19111: Using EXPLAIN ANALYZE with MERGE causes failed assert |
| Дата | |
| Msg-id | CAEZATCWqE70qVHv6fbdEXVrD7=hCQ_quKRKnirmukMqaKO5T=Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | BUG #19111: Using EXPLAIN ANALYZE with MERGE causes failed assert (PG Bug reporting form <noreply@postgresql.org>) |
| Ответы |
Re: BUG #19111: Using EXPLAIN ANALYZE with MERGE causes failed assert
|
| Список | pgsql-bugs |
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
Вложения
В списке pgsql-bugs по дате отправления: