On Mon, Sep 30, 2013 at 3:45 PM, Peter Geoghegan <p...@heroku.com> wrote: > If you think it's a bit odd that we lock every value while the user > essentially has one constraint in mind when writing their DML, > consider:
I should add to that list: 4) Locking all the values at once is necessary for the behavior of the locking to be well-defined -- I feel we need to know that some exact tuple is to blame (according to our well defined ordering for checking unique indexes for conflicts) for at least one instant in time. Given that we need to be the first to change the row without anything being altered to it, this ought to be sufficient. If you think it's bad that some other session can come in and insert a tuple that would have caused us to decide differently (before *our* transaction commits but *after* we've inserted), now you're into blaming the *wrong* tuple in the future, and I can't get excited about that - we always prefer a tuple normally visible to our snapshot, but if forced to (if there is none) we just throw a serialization failure (where appropriate). So for read committed you can have no *principled* beef with this, but for serializable you're going to naturally prefer the currently-visible tuple generally (that's the only correct behavior there that won't error - there *better* be something visible). Besides, the way the user tacitly has to use the feature with one particular constraint in mind kind of implies that this cannot happen... -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers