Re: Promise index tuples for UPSERT - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Promise index tuples for UPSERT
Date
Msg-id CAM3SWZQ-gU1gwycz8ok0Fa5T_XW5P1bz9fNba1g6dOd-Nvks6g@mail.gmail.com
Whole thread Raw
In response to Re: Promise index tuples for UPSERT  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On Fri, Oct 3, 2014 at 3:54 AM, Heikki Linnakangas
<hlinnakangas@vmware.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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)
Next
From: Andres Freund
Date:
Subject: Re: Last Commitfest patches waiting review