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

Commit81f4c28

Browse files
committed
Improve documentation about multixact IDs.
Per gripe from Josh Berkus.
1 parent6fc2868 commit81f4c28

File tree

2 files changed

+17
-12
lines changed

2 files changed

+17
-12
lines changed

‎doc/src/sgml/maintenance.sgml

Lines changed: 12 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -618,13 +618,16 @@ HINT: Stop the postmaster and use a standalone backend to VACUUM in "mydb".
618618
</indexterm>
619619

620620
<para>
621-
<firstterm>Multixacts</> are used to implement row locking by
622-
multiple transactions: since there is limited space in the tuple
623-
header to store lock information, that information is stored as a
624-
multixact separately in the <filename>pg_multixact</> subdirectory,
625-
and only its ID is in the <structfield>xmax</> field
626-
in the tuple header.
627-
Similar to transaction IDs, multixact IDs are implemented as a
621+
<firstterm>Multixact IDs</> are used to support row locking by
622+
multiple transactions. Since there is only limited space in a tuple
623+
header to store lock information, that information is encoded as
624+
a <quote>multiple transaction ID</>, or multixact ID for short,
625+
whenever there is more than one transaction concurrently locking a
626+
row. Information about which transaction IDs are included in any
627+
particular multixact ID is stored separately in
628+
the <filename>pg_multixact</> subdirectory, and only the multixact ID
629+
appears in the <structfield>xmax</> field in the tuple header.
630+
Like transaction IDs, multixact IDs are implemented as a
628631
32-bit counter and corresponding storage, all of which requires
629632
careful aging management, storage cleanup, and wraparound handling.
630633
</para>
@@ -636,8 +639,8 @@ HINT: Stop the postmaster and use a standalone backend to VACUUM in "mydb".
636639
is replaced by a different value, which can be the zero value, a single
637640
transaction ID, or a newer multixact ID. For each table,
638641
<structname>pg_class</>.<structfield>relminmxid</> stores the oldest
639-
possiblevaluestillstored in any tuple of that table. Every time this
640-
value is older than
642+
possiblemultixact IDstillappearing in any tuple of that table.
643+
If thisvalue is older than
641644
<xref linkend="guc-vacuum-multixact-freeze-table-age">, a whole-table
642645
scan is forced. Whole-table <command>VACUUM</> scans, regardless of
643646
what causes them, enable advancing the value for that table.

‎doc/src/sgml/release-9.3.sgml

Lines changed: 5 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -64,9 +64,11 @@ Branch: REL9_3_STABLE [8e9a16ab8] 2013-12-16 11:29:51 -0300
6464
</para>
6565

6666
<para>
67-
The method for tuple freezing was unable to handle some cases
68-
involving freezing of <quote>multixact</> IDs, with the practical
69-
effect that shared row-level locks might be forgotten once old enough.
67+
The logic for tuple freezing was unable to handle some cases involving
68+
freezing of
69+
<link linkend="vacuum-for-multixact-wraparound"><firstterm>multixact</>
70+
IDs</link>, with the practical effect that shared row-level locks
71+
might be forgotten once old enough.
7072
</para>
7173

7274
<para>

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp