On Fri, Oct 3, 2014 at 2:50 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> My view is that I can't see the above use case from happening in real
> situations, except by infrequent mistake. In most cases, unique
> indexes represent some form of object identity and those don't change
> frequently in the real world. So to be changing two unique fields at
> the same time and it not representing some form of business process
> error that people would like to see fail anyway, I'd be surprised by.
Are we talking about two different things here?
Unprincipled deadlocks can be seen without updating any constrained
column in the UPSERT. The test-case that originally highlighted the
issue only had one unique index, and it was *not* in the update's
targetlist. See:
https://wiki.postgresql.org/wiki/Value_locking#.22Unprincipled_Deadlocking.22_and_value_locking
--
Peter Geoghegan