| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(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 21:17:42 |
| Message-ID: | CAM3SWZQ-gU1gwycz8ok0Fa5T_XW5P1bz9fNba1g6dOd-Nvks6g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Oct 3, 2014 at 3:54 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> Simon's approach would actually pass that test case just fine. It inserts
> the (promise) index tuple first, and heap tuple only after that. It will
> fail the test case with more than one unique index, however.
Oh, I see. Still, I don't think you need to UPDATE a
uniquely-constrained attribute - even if updating constrained
attributes is rare (dubious), non-HOT updates will have the same
effect, no? I still think that's unacceptable.
In any case, I still don't see what this buys us over the other two
designs. What's the pay-off for giving up on the general avoidance of
unprincipled deadlocks?
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2014-10-03 21:19:16 | Re: Last Commitfest patches waiting review |
| Previous Message | Andres Freund | 2014-10-03 21:16:53 | Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept) |