Hi, On 2015-05-10 16:01:53 -0400, Tom Lane wrote: > The cause of the problem seems to be that the UPDATE performs a HOT update > of the new tuple, leaving in this case a dead tuple at (0,2) that is HOT > updated by (0,3). When unique_key_recheck() is invoked for (0,2), it > believes, correctly, that it has to perform the recheck anyway ... but it > tells check_exclusion_constraint that the check is being performed for > (0,2). So the index search inside check_exclusion_constraint finds the > live tuple at (0,3) and thinks that is a conflict.
Heh, it's curious that this wasn't found up until now. I also wonder if this might be related to the spurious violations Peter G. has been observing... > The attached patch seems to fix the problem without breaking any existing > regression tests, but I wonder if anyone can see a hole in it. Looks good to me. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
