Re: BUG #14972: row duplicate on first SELECT from CTE (by JOIN/FORUPDATE) from which UPDATE performed recently - Mailing list pgsql-bugs

From Evgeniy Kozlov
Subject Re: BUG #14972: row duplicate on first SELECT from CTE (by JOIN/FORUPDATE) from which UPDATE performed recently
Date
Msg-id 75050b5d-b426-500d-e6bd-d7025a1d018d@gmail.com
Whole thread Raw
In response to 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>)
Responses Re: BUG #14972: row duplicate on first SELECT from CTE (by JOIN/FORUPDATE) from which UPDATE performed recently  (Marko Tiikkaja <marko@joh.to>)
List pgsql-bugs

2017-12-13 23:14 (+03), David G. Johnston wrote:

On Wed, Dec 13, 2017 at 12:12 PM, <dsuchka@gmail.com> wrote:
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 1

​Can 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.
Just tested on 9.5.10 and 9.6.6 — both have the same problem.

Best regards, Evgeniy Kozlov.

pgsql-bugs by date:

Previous
From: Michael Paquier
Date:
Subject: Re: BUG #14952: COPY fails to fill in IDENTITY column default value
Next
From: Alvaro Herrera
Date:
Subject: Re: BUG #14963: Number of wal files are keep on increasing