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
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>
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
