mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update README.tuplock

Browse Source 
This file was documenting an older version of patch 0ac5ad5134; update
it to match what was really committed

Author: Florian Pflug
This commit is contained in:
Alvaro Herrera 2014-10-23 20:51:58 -03:00
parent 43ac12c6e6
commit b01a4f6838
1 changed files with 17 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
src/backend/access/heap/README.tuplock
View File

@ -36,22 +36,25 @@ do LockTuple as well, if there is any conflict, to ensure that they don't
starve out waiting exclusive-lockers. However, if there is not any active starve out waiting exclusive-lockers. However, if there is not any active
conflict for a tuple, we don't incur any extra overhead. conflict for a tuple, we don't incur any extra overhead.
We provide four levels of tuple locking strength: SELECT FOR KEY UPDATE is We provide four levels of tuple locking strength: SELECT FOR UPDATE obtains an
super-exclusive locking (used to delete tuples and more generally to update exclusive lock which prevents any kind of modification of the tuple. This is
tuples modifying the values of the columns that make up the key of the tuple); the lock level that is implicitly taken by DELETE operations, and also by
SELECT FOR UPDATE is a standards-compliant exclusive lock; SELECT FOR SHARE UPDATE operations if they modify any of the tuple's key fields. SELECT FOR NO
implements shared locks; and finally SELECT FOR KEY SHARE is a super-weak mode KEY UPDATE likewise obtains an exclusive lock, but only prevents tuple removal
that does not conflict with exclusive mode, but conflicts with SELECT FOR KEY and modifications which might alter the tuple's key. This is the lock that is
UPDATE. This last mode implements a mode just strong enough to implement RI implicitly taken by UPDATE operations which leave all key fields unchanged.
checks, i.e. it ensures that tuples do not go away from under a check, without SELECT FOR SHARE obtains a shared lock which prevents any kind of tuple
blocking when some other transaction that want to update the tuple without modification. Finally, SELECT FOR KEY SHARE obtains a shared lock which only
changing its key. prevents tuple removal and modifications of key fields. 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.
The conflict table is: The conflict table is:
KEY UPDATE UPDATE SHARE KEY SHARE UPDATE NO KEY UPDATE SHARE KEY SHARE
KEY UPDATE conflict conflict conflict conflict UPDATE conflict conflict conflict conflict
UPDATE conflict conflict conflict NO KEY UPDATE conflict conflict conflict
SHARE conflict conflict SHARE conflict conflict
KEY SHARE conflict KEY SHARE conflict
@ -127,7 +130,7 @@ The following infomask bits are applicable:
the member flags. If HEAP_XMAX_IS_MULTI is not set and HEAP_XMAX_LOCK_ONLY the member flags. If HEAP_XMAX_IS_MULTI is not set and HEAP_XMAX_LOCK_ONLY
is set, then one of these *must* be set as well. is set, then one of these *must* be set as well.
Note there is no infomask bit for a SELECT FOR SHARE lock. Also there is no Note there is no infomask bit for a SELECT FOR SHARE lock. Also there is no
separate bit for a SELECT FOR KEY UPDATE lock; this is implemented by the separate bit for a SELECT FOR NO KEY UPDATE lock; this is implemented by the
HEAP_KEYS_UPDATED bit. HEAP_KEYS_UPDATED bit.
- HEAP_KEYS_UPDATED - HEAP_KEYS_UPDATED