DOC: bug fix for 64-bit xids - PGPRO-578

Author: Liudmila Mantrova

doc/src/sgml/datatype.sgml

@@ -4605,13 +4605,16 @@ SELECT * FROM pg_attribute
    <para>
     Another identifier type used by the system is <type>xid</>, or transaction
     (abbreviated <abbrev>xact</>) identifier.  This is the data type of the system columns
-    <structfield>xmin</> and <structfield>xmax</>.  Transaction identifiers are 32-bit quantities.
+    <structfield>xmin</> and <structfield>xmax</>.
+    In <productname>&productname;</productname>, transaction IDs
+    are implemented as 64-bit counters to prevent transaction ID wraparound.
+    For details, see <xref linkend="vacuum-for-wraparound">.
    </para>
 
    <para>
     A third identifier type used by the system is <type>cid</>, or
     command identifier.  This is the data type of the system columns
-    <structfield>cmin</> and <structfield>cmax</>. Command identifiers are also 32-bit quantities.
+    <structfield>cmin</> and <structfield>cmax</>. Command identifiers are 32-bit quantities.
    </para>
 
    <para>

doc/src/sgml/ddl.sgml

@@ -1097,16 +1097,13 @@ CREATE TABLE circles (
    </para>
 
    <para>
-    Transaction identifiers are also 32-bit quantities.  In a
-    long-lived database it is possible for transaction IDs to wrap
-    around.  This is not a fatal problem given appropriate maintenance
-    procedures; see <xref linkend="maintenance"> for details.  It is
-    unwise, however, to depend on the uniqueness of transaction IDs
-    over the long term (more than one billion transactions).
+    In <productname>&productname;</productname>, transaction IDs
+    are implemented as 64-bit counters to prevent transaction ID wraparound.
+    For details, see <xref linkend="vacuum-for-wraparound">.
    </para>
 
    <para>
-    Command identifiers are also 32-bit quantities.  This creates a hard limit
+    Command identifiers are 32-bit quantities.  This creates a hard limit
     of 2<superscript>32</> (4 billion) <acronym>SQL</acronym> commands
     within a single transaction.  In practice this limit is not a
     problem &mdash; note that the limit is on the number of

doc/src/sgml/func.sgml

@@ -17771,8 +17771,9 @@ SELECT collation for ('foo' COLLATE "de_DE");
    </table>
 
    <para>
-    The internal transaction ID type (<type>xid</>) is 32 bits wide and
-    wraps around every 4 billion transactions.  However, these functions
+    In <productname>&productname;</productname>, transaction IDs
+    are implemented as 64-bit counters to prevent transaction ID wraparound.
+    The following functions
     export a 64-bit format that is extended with an <quote>epoch</> counter
     so it will not wrap around during the life of an installation.
     The data type used by these functions, <type>txid_snapshot</type>,

doc/src/sgml/maintenance.sgml

@@ -405,7 +405,7 @@
     <productname>Postgres Pro Enterprise 9.6</productname> introduced
     64-bit transaction IDs, which are not subject to wraparound and
     do not need modulo-2<superscript>32</> arithmetic to be compared.
-    Each tuple header contain two XIDs, so extending them would lead to
+    Each tuple header contains two XIDs, so extending them would lead to
     high overhead.  For that reason on-page XIDs are still 32-bit, but
     each page's header contains an offset, called <firstterm>epoch</>,
     to which they are added before comparing with each other.