Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitcdbdc43

Browse files
committed
Update README.tuplock
Multixact truncation is now handled differently, and this file hadn'tgotten 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 upto date either. This commit also propagatesb01a4f6 back to 9.3 and9.4, which apparently I failed to do back then.
1 parent6739aa2 commitcdbdc43

File tree

1 file changed

+10
-8
lines changed

1 file changed

+10
-8
lines changed

‎src/backend/access/heap/README.tuplock

Lines changed: 10 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -100,11 +100,12 @@ that pg_multixact needs to retain pages of its data until we're certain that
100100
the MultiXacts in them are no longer of interest.
101101

102102
VACUUM is in charge of removing old MultiXacts at the time of tuple freezing.
103-
This works in the same way that pg_clog segments are removed: we have a
104-
pg_class column that stores the earliest multixact that could possibly be
105-
stored in the table; the minimum of all such values is stored in a pg_database
106-
column. VACUUM computes the minimum across all pg_database values, and
107-
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.
108109

109110
Infomask Bits
110111
-------------
@@ -124,14 +125,15 @@ The following infomask bits are applicable:
124125
the XMAX is a plain Xid that locked the tuple, as well.
125126

126127
- HEAP_XMAX_KEYSHR_LOCK
128+
- HEAP_XMAX_SHR_LOCK
127129
- HEAP_XMAX_EXCL_LOCK
128130
These bits indicate the strength of the lock acquired; they are useful when
129131
the XMAX is not a MultiXactId. If it's a multi, the info is to be found in
130132
the member flags. If HEAP_XMAX_IS_MULTI is not set and HEAP_XMAX_LOCK_ONLY
131133
is set, then one of these *must* be set as well.
132-
Note there is no infomask bit for a SELECT FOR SHARE lock. Also there is no
133-
separate bit for a SELECTFOR NO KEY UPDATElock; this is implemented by the
134-
HEAP_KEYS_UPDATED bit.
134+
135+
Note that HEAP_XMAX_EXCL_LOCK does not distinguishFOR NO KEY UPDATEfrom
136+
FOR UPDATE; this is implemented by theHEAP_KEYS_UPDATED bit.
135137

136138
- HEAP_KEYS_UPDATED
137139
This bit lives in t_infomask2. If set, indicates that the XMAX updated

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp