Update README.tuplock

Multixact truncation is now handled differently, and this file hadn't
gotten the memo.

Per note from Amit Langote.  I didn't use his patch, though.

Also update the description of infomask bits, which weren't completely up
to date either.  This commit also propagates b01a4f6838 back to 9.3 and
9.4, which apparently I failed to do back then.

1 files changed, 26 insertions, 21 deletions

diff --git a/src/backend/access/heap/README.tuplock b/src/backend/access/heap/README.tuplock
index 8d5cc167c83..970883e004f 100644
--- a/src/backend/access/heap/README.tuplock
+++ b/src/backend/access/heap/README.tuplock
@@ -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
 conflict for a tuple, we don't incur any extra overhead.
 
-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.
+We provide four levels of tuple locking strength: SELECT FOR UPDATE obtains an
+exclusive lock which prevents any kind of modification of the tuple. This is
+the lock level that is implicitly taken by DELETE operations, and also by
+UPDATE operations if they modify any of the tuple's key fields. SELECT FOR NO
+KEY UPDATE likewise obtains an exclusive lock, but only prevents tuple removal
+and modifications which might alter the tuple's key. This is the lock that is
+implicitly taken by UPDATE operations which leave all key fields unchanged.
+SELECT FOR SHARE obtains a shared lock which prevents any kind of tuple
+modification. Finally, SELECT FOR KEY SHARE obtains a shared lock which only
+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:
 
-                KEY UPDATE        UPDATE        SHARE        KEY SHARE
-KEY UPDATE       conflict        conflict      conflict      conflict
-UPDATE           conflict        conflict      conflict
+                  UPDATE       NO KEY UPDATE    SHARE        KEY SHARE
+UPDATE           conflict        conflict      conflict      conflict
+NO KEY UPDATE    conflict        conflict      conflict
 SHARE            conflict        conflict
 KEY SHARE        conflict
 
@@ -97,11 +100,12 @@ that pg_multixact needs to retain pages of its data until we're certain that
 the MultiXacts in them are no longer of interest.
 
 VACUUM is in charge of removing old MultiXacts at the time of tuple freezing.
-This works in the same way that pg_clog segments are removed: we have a
-pg_class column that stores the earliest multixact that could possibly be
-stored in the table; the minimum of all such values is stored in a pg_database
-column.  VACUUM computes the minimum across all pg_database values, and
-removes pg_multixact segments older than the minimum.
+The lower bound used by vacuum (that is, the value below which all multixacts
+are removed) is stored as pg_class.relminmxid for each table; the minimum of
+all such values is stored in pg_database.datminmxid.  The minimum across
+all databases, in turn, is recorded in checkpoint records, and CHECKPOINT
+removes pg_multixact/ segments older than that value once the checkpoint
+record has been flushed.
 
 Infomask Bits
 -------------
@@ -121,14 +125,15 @@ The following infomask bits are applicable:
   the XMAX is a plain Xid that locked the tuple, as well.
 
 - HEAP_XMAX_KEYSHR_LOCK
+- HEAP_XMAX_SHR_LOCK
 - HEAP_XMAX_EXCL_LOCK
   These bits indicate the strength of the lock acquired; they are useful when
   the XMAX is not a MultiXactId.  If it's a multi, the info is to be found in
   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.
-  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
-  HEAP_KEYS_UPDATED bit.
+
+  Note that HEAP_XMAX_EXCL_LOCK does not distinguish FOR NO KEY UPDATE from
+  FOR UPDATE; this is implemented by the HEAP_KEYS_UPDATED bit.
 
 - HEAP_KEYS_UPDATED
   This bit lives in t_infomask2.  If set, indicates that the XMAX updated