Re: BUG #14972: row duplicate on first SELECT from CTE (by JOIN/FORUPDATE) from which UPDATE performed recently
| От | Evgeniy Kozlov |
|---|---|
| Тема | Re: BUG #14972: row duplicate on first SELECT from CTE (by JOIN/FORUPDATE) from which UPDATE performed recently |
| Дата | |
| Msg-id | 75050b5d-b426-500d-e6bd-d7025a1d018d@gmail.com обсуждение |
| Ответ на | Re: BUG #14972: row duplicate on first SELECT from CTE (by JOIN/FORUPDATE) from which UPDATE performed recently ("David G. Johnston" <david.g.johnston@gmail.com>) |
| Ответы |
Re: BUG #14972: row duplicate on first SELECT from CTE (by JOIN/FORUPDATE) from which UPDATE performed recently
|
| Список | pgsql-bugs |
2017-12-13 23:14 (+03), David G. Johnston wrote:
Just tested on 9.5.10 and 9.6.6 — both have the same problem.The following bug has been logged on the website:
Bug reference: 14972
Logged by: Evgeniy Kozlov
Email address: dsuchka@gmail.com
PostgreSQL version: 9.5.5
Operating system: gentoo, debian
Description:
Since ON CONFLICT does not work with partitions, I have designed an
aggregation appender by hand using UPDATE (for existed rows) + INSERT (for
new ones). Unexpectedly I got a strange result as a count of updated (really
joined) rows running that function cuncurrently on 9.5.5 and 9.5.7 (9.5.2
works correctly).
The got value exceeds the expected result by 1Can you run this against 9.5.10 and see if it is still a problem? Its seems the last couple of bug fix patches covered something that sounds familiar.David J.
Best regards, Evgeniy Kozlov.
В списке pgsql-bugs по дате отправления: