Doc: small improvements for documentation about VACUUM freezing.

Mostly, explain how row xmin's used to be replaced by FrozenTransactionId
and no longer are.  Do a little copy-editing on the side.

Per discussion with Egor Rogov.  Back-patch to 9.4 where the behavioral
change occurred.

Discussion: <575D7955.6060209@postgrespro.ru>

diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 5204b34c75abc435b4cc39d56de8aed77300e728..74f5de835ebeedd9592fa0021d547a1d8a6d535f 100644 (file)
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -386,7 +386,8 @@
     
 
    
-    PostgreSQL's MVCC transaction semantics
+    PostgreSQL's
+    MVCC transaction semantics
     depend on being able to compare transaction ID (XID)
     numbers: a row version with an insertion XID greater than the current
     transaction's XID is in the future and should not be visible
@@ -404,13 +405,10 @@
    
     The reason that periodic vacuuming solves the problem is that
     VACUUM will mark rows as 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.
-    PostgreSQL reserves a special XID,
-    FrozenTransactionId, which does not follow the normal XID
-    comparison rules and is always considered older
-    than every normal XID. Normal XIDs are
+    they were inserted by a transaction that committed sufficiently far in
+    the past that the effects of the inserting transaction are certain to be
+    visible to all current and future transactions.
+    Normal XIDs are
     compared using modulo-232 arithmetic. This means
     that for every normal XID, there are two billion XIDs that are
     older and two billion that are newer; another
@@ -420,16 +418,40 @@
     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
+    prevent this, PostgreSQL reserves a special XID,
+    FrozenTransactionId, which does not follow the normal XID
+    comparison rules and is always considered older
+    than every normal XID.
+    Frozen row versions are treated as if the inserting XID were
     FrozenTransactionId, so that they will appear to be
     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.
    
 
+   
+    
+     In PostgreSQL versions before 9.4, freezing was
+     implemented by actually replacing a row's insertion XID
+     with FrozenTransactionId, which was visible in the
+     row's xmin system column.  Newer versions just set a flag
+     bit, preserving the row's original xmin for possible
+     forensic use.  However, rows with xmin equal
+     to FrozenTransactionId (2) may still be found
+     in databases pg_upgrade'd from pre-9.4 versions.
+    
+    
+     Also, system catalogs may contain rows with xmin equal
+     to BootstrapTransactionId (1), indicating that they were
+     inserted during the first phase of initdb.
+     Like FrozenTransactionId, this special XID is treated as
+     older than every normal XID.
+    
+   
+
    
     
-    controls how old an XID value has to be before its row version will be
+    controls how old an XID value has to be before rows bearing that XID will be
     frozen.  Increasing this setting may avoid unnecessary work if the
     rows that would otherwise be frozen will soon be modified again,
     but decreasing this setting increases