rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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.
This commit is contained in:
Alvaro Herrera 2015-05-25 15:09:05 -03:00
parent 6739aa298b
commit cdbdc43827
1 changed files with 10 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -100,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. the MultiXacts in them are no longer of interest.
VACUUM is in charge of removing old MultiXacts at the time of tuple freezing. 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 The lower bound used by vacuum (that is, the value below which all multixacts
pg_class column that stores the earliest multixact that could possibly be are removed) is stored as pg_class.relminmxid for each table; the minimum of
stored in the table; the minimum of all such values is stored in a pg_database all such values is stored in pg_database.datminmxid. The minimum across
column. VACUUM computes the minimum across all pg_database values, and all databases, in turn, is recorded in checkpoint records, and CHECKPOINT
removes pg_multixact segments older than the minimum. removes pg_multixact/ segments older than that value once the checkpoint
record has been flushed.
Infomask Bits Infomask Bits
------------- -------------
@ -124,14 +125,15 @@ The following infomask bits are applicable:
the XMAX is a plain Xid that locked the tuple, as well. the XMAX is a plain Xid that locked the tuple, as well.
- HEAP_XMAX_KEYSHR_LOCK - HEAP_XMAX_KEYSHR_LOCK
- HEAP_XMAX_SHR_LOCK
- HEAP_XMAX_EXCL_LOCK - HEAP_XMAX_EXCL_LOCK
These bits indicate the strength of the lock acquired; they are useful when 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 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 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
separate bit for a SELECT FOR NO KEY UPDATE lock; this is implemented by the Note that HEAP_XMAX_EXCL_LOCK does not distinguish FOR NO KEY UPDATE from
HEAP_KEYS_UPDATED bit. FOR UPDATE; this is implemented by the HEAP_KEYS_UPDATED bit.
- HEAP_KEYS_UPDATED - HEAP_KEYS_UPDATED
This bit lives in t_infomask2. If set, indicates that the XMAX updated This bit lives in t_infomask2. If set, indicates that the XMAX updated