Preliminary comment: This README is very helpful.
On Tue, Mar 6, 2012 at 2:39 PM, Alvaro Herrera <alvhe...@commandprompt.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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
