| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: "Value locking" Wiki page |
| Date: | 2014-10-01 19:06:23 |
| Message-ID: | CAM3SWZTRuyjhgNMAKFZo64GvZG9eh02Qw67_j=iCjQdiAUomJg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Oct 1, 2014 at 6:49 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> Well, if nothing else, it would be nice to fix the concurrency issue we have
> with exclusion constraints today, which is that if two backends insert the
> same value at the same time, they might both get an error, even though you'd
> only need to abort one of them. That's a special case of UPSERT if you
> squint a little.
In my view, it makes sense to fix that, and to make INSERT ... ON
CONFLICT IGNORE work with exclusion constraints. However, it does not
make sense to have INSERT ... ON CONFLICT UPDATE work with exclusion
constraints. The user-visible semantics are very tricky, and I don't
think it's useful.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2014-10-01 19:09:22 | Re: autovacuum scheduling starvation and frenzy |
| Previous Message | Andres Freund | 2014-10-01 19:04:25 | Re: Scaling shared buffer eviction |