Re: foreign key locks, 2nd attempt

On Tue, Mar 6, 2012 at 9:10 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Preliminary comment:
>
> This README is very helpful.
>
> On Tue, Mar 6, 2012 at 2:39 PM, Alvaro Herrera
> <alvherre(at)commandprompt(dot)com> wrote:
>> We provide four levels of tuple locking strength: SELECT FOR KEY UPDATE is
>> super-exclusive locking (used to delete tuples and more generally to update
>> tuples modifying the values of the columns that make up the key of the tuple);
>> SELECT FOR UPDATE is a standards-compliant exclusive lock; SELECT FOR SHARE
>> implements shared locks; and finally SELECT FOR KEY SHARE is a super-weak mode
>> that does not conflict with exclusive mode, but conflicts with SELECT FOR KEY
>> UPDATE.  This last mode implements a mode just strong enough to implement RI
>> checks, i.e. it ensures that tuples do not go away from under a check, without
>> blocking when some other transaction that want to update the tuple without
>> changing its key.
>
> I feel like there is a naming problem here.  The semantics that have
> always been associated with SELECT FOR UPDATE are now attached to
> SELECT FOR KEY UPDATE; and SELECT FOR UPDATE itself has been weakened.
>  I think users will be surprised to find that SELECT FOR UPDATE
> doesn't block all concurrent updates.
>
> It seems to me that SELECT FOR KEY UPDATE should be called SELECT FOR
> UPDATE, and what you're calling SELECT FOR UPDATE should be called
> something else - essentially NONKEY UPDATE, though I don't much like
> that name.

No, because that would stop it from doing what it is designed to do.

The lock modes are correct, appropriate and IMHO have meaningful
names. No redesign required here.

Not sure about the naming of some of the flag bits however.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services