From: Egor Rogov <e.rogov@postgrespro.ru>
Subject: FrozenTransactionId
To: pgsql-docs@postgresql.org
Message-ID: <575D7955.6060209@postgrespro.ru>
Date: Sun, 12 Jun 2016 18:01:41 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.2
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="------------030701020808000009080206"
Precedence: bulk
Sender: pgsql-docs-owner@postgresql.org

This is a multi-part message in MIME format.
--------------030701020808000009080206
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,
Since 9.4 FrozenTransactionId is no longer used to freeze row versions. 
The change was done by commit 37484ad:

 >     Instead of changing the tuple xmin to FrozenTransactionId, the 
combination
 >     of HEAP_XMIN_COMMITTED and HEAP_XMIN_INVALID, which were 
previously never
 >     set together, is now defined as HEAP_XMIN_FROZEN.

But we still have FrozenTransactionId mentioned in section 23.1.5.
Please consider the attached patch to fix it.

Thanks,
Egor Rogov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


--------------030701020808000009080206
Content-Type: text/x-patch;
 name="maintenance.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="maintenance.patch"

diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 5204b34..8b966cc 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -403,28 +403,22 @@
 
    <para>
     The reason that periodic vacuuming solves the problem is that
-    <command>VACUUM</> will mark rows as <emphasis>frozen</>, indicating that
-    they were inserted by a transaction which committed sufficiently far in
-    the past that the effects of the inserting transaction is certain to be
-    visible, from an MVCC perspective, to all current and future transactions.
-    <productname>PostgreSQL</> reserves a special XID,
-    <literal>FrozenTransactionId</>, which does not follow the normal XID
-    comparison rules and is always considered older
-    than every normal XID. Normal XIDs are
-    compared using modulo-2<superscript>32</> arithmetic. This means
-    that for every normal XID, there are two billion XIDs that are
-    <quote>older</> and two billion that are <quote>newer</>; another
-    way to say it is that the normal XID space is circular with no
-    endpoint. Therefore, once a row version has been created with a particular
-    normal XID, the row version will appear to be <quote>in the past</> for
-    the next two billion transactions, no matter which normal XID we are
-    talking about. If the row version still exists after more than two billion
-    transactions, it will suddenly appear to be in the future. To
-    prevent this, frozen row versions are treated as if the inserting XID were
-    <literal>FrozenTransactionId</>, so that they will appear to be
-    <quote>in the past</> to all normal transactions regardless of wraparound
-    issues, and so such row versions will be valid until deleted, no matter
-    how long that is.
+    <command>VACUUM</> will mark rows as <emphasis>frozen</> (by setting
+    appropriate hint bits), indicating that they were inserted by a transaction
+    which committed sufficiently far in the past that the effects of the
+    inserting transaction is certain to be visible, from an MVCC perspective,
+    to all current and future transactions.  Usually XIDs are compared using
+    modulo-2<superscript>32</> arithmetic. This means that for every XID, there
+    are two billion XIDs that are <quote>older</> and two billion that are
+    <quote>newer</>; another way to say it is that the XID space is circular
+    with no endpoint. Therefore, once a row version has been created with a
+    particular XID, the row version will appear to be <quote>in the past</> for
+    the next two billion transactions. If the row version still exists after
+    more than two billion transactions, it will suddenly appear to be in the
+    future. To prevent this, usual visibility rules are not applied to frozen
+    row versions. Instead they are considered to be <quote>in the past</> to
+    all transactions regardless of wraparound issues, and so such row versions
+    will be valid until deleted, no matter how long that is.
    </para>
 
    <para>

--------------030701020808000009080206
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


-- 
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

--------------030701020808000009080206--