@@ -36,22 +36,25 @@ do LockTuple as well, if there is any conflict, to ensure that they don't
3636starve out waiting exclusive-lockers. However, if there is not any active
3737conflict for a tuple, we don't incur any extra overhead.
3838
39- We provide four levels of tuple locking strength: SELECT FOR KEY UPDATE is
40- super-exclusive locking (used to delete tuples and more generally to update
41- tuples modifying the values of the columns that make up the key of the tuple);
42- SELECT FOR UPDATE is a standards-compliant exclusive lock; SELECT FOR SHARE
43- implements shared locks; and finally SELECT FOR KEY SHARE is a super-weak mode
44- that does not conflict with exclusive mode, but conflicts with SELECT FOR KEY
45- UPDATE. This last mode implements a mode just strong enough to implement RI
46- checks, i.e. it ensures that tuples do not go away from under a check, without
47- blocking when some other transaction that want to update the tuple without
48- changing its key.
39+ We provide four levels of tuple locking strength: SELECT FOR UPDATE obtains an
40+ exclusive lock which prevents any kind of modification of the tuple. This is
41+ the lock level that is implicitly taken by DELETE operations, and also by
42+ UPDATE operations if they modify any of the tuple's key fields. SELECT FOR NO
43+ KEY UPDATE likewise obtains an exclusive lock, but only prevents tuple removal
44+ and modifications which might alter the tuple's key. This is the lock that is
45+ implicitly taken by UPDATE operations which leave all key fields unchanged.
46+ SELECT FOR SHARE obtains a shared lock which prevents any kind of tuple
47+ modification. Finally, SELECT FOR KEY SHARE obtains a shared lock which only
48+ prevents tuple removal and modifications of key fields. This last mode
49+ implements a mode just strong enough to implement RI checks, i.e. it ensures
50+ that tuples do not go away from under a check, without blocking when some
51+ other transaction that want to update the tuple without changing its key.
4952
5053The conflict table is:
5154
52- KEY UPDATE UPDATE SHARE KEY SHARE
53- KEY UPDATE conflict conflict conflict conflict
54- UPDATE conflict conflict conflict
55+ NO KEY UPDATE SHARE KEY SHARE
56+ UPDATE
57+ NO KEY UPDATE conflict conflict conflict
5558SHARE conflict conflict
5659KEY SHARE conflict
5760
@@ -97,11 +100,12 @@ that pg_multixact needs to retain pages of its data until we're certain that
97100the MultiXacts in them are no longer of interest.
98101
99102VACUUM is in charge of removing old MultiXacts at the time of tuple freezing.
100- This works in the same way that pg_clog segments are removed: we have a
101- pg_class column that stores the earliest multixact that could possibly be
102- stored in the table; the minimum of all such values is stored in a pg_database
103- column. VACUUM computes the minimum across all pg_database values, and
104- removes pg_multixact segments older than the minimum.
103+ The lower bound used by vacuum (that is, the value below which all multixacts
104+ are removed) is stored as pg_class.relminmxid for each table; the minimum of
105+ all such values is stored in pg_database.datminmxid. The minimum across
106+ all databases, in turn, is recorded in checkpoint records, and CHECKPOINT
107+ removes pg_multixact/ segments older than that value once the checkpoint
108+ record has been flushed.
105109
106110Infomask Bits
107111-------------
@@ -121,14 +125,15 @@ The following infomask bits are applicable:
121125 the XMAX is a plain Xid that locked the tuple, as well.
122126
123127- HEAP_XMAX_KEYSHR_LOCK
128+ - HEAP_XMAX_SHR_LOCK
124129- HEAP_XMAX_EXCL_LOCK
125130 These bits indicate the strength of the lock acquired; they are useful when
126131 the XMAX is not a MultiXactId. If it's a multi, the info is to be found in
127132 the member flags. If HEAP_XMAX_IS_MULTI is not set and HEAP_XMAX_LOCK_ONLY
128133 is set, then one of these *must* be set as well.
129- Note there is no infomask bit for a SELECT FOR SHARE lock. Also there is no
130- separate bit for a SELECT FOR KEY UPDATElock; this is implemented by the
131- HEAP_KEYS_UPDATED bit.
134+
135+ Note that HEAP_XMAX_EXCL_LOCK does not distinguish FORNO KEY UPDATEfrom
136+ FOR UPDATE; this is implemented by the HEAP_KEYS_UPDATED bit.
132137
133138- HEAP_KEYS_UPDATED
134139 This bit lives in t_infomask2. If set, indicates that the XMAX updated