On 10/05/2015 10:01 PM, 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.
>
> This is reproducible clear back to 9.0 where exclusion constraints were
> added.
>
> The easiest fix seems to be to pass the HOT child's TID instead of the
> TID we were called for. (Note that the other path, for a regular unique
> constraint, is correct as-is because the original TID is what the index
> will know about.)
>
> 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.
>
> regards, tom lane
>
Thanks very much for fixing this! Now that you know the cause, could you
suggest any workaround?
Also, any idea when the fix will be released? Will it be in 9.3.7 or
9.4.2 or only in 9.5.0?