| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)2ndquadrant(dot)com> |
| Subject: | Re: Promise index tuples for UPSERT |
| Date: | 2014-10-03 09:57:06 |
| Message-ID: | CAM3SWZT=ddhbLSd2-3RPzwLTDogAY3mEjsfofLEa4bn7Pb9Nkg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Oct 3, 2014 at 2:50 AM, Simon Riggs <simon(at)2ndquadrant(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2014-10-03 10:04:42 | Re: Promise index tuples for UPSERT |
| Previous Message | Simon Riggs | 2014-10-03 09:50:47 | Re: Promise index tuples for UPSERT |