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 2713883019e1df88a4aafef342b8780b3962c529..f87f3e00de5b7b1ef31abf764780bcaafca45eb1 100644 (file)
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -389,7 +389,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
@@ -407,13 +408,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
@@ -423,16 +421,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
@@ -442,10 +464,10 @@
 
    
     VACUUM uses the visibility map
-    to determine which pages of a relation must be scanned.  Normally, it
-    will skips pages that don't have any dead row versions even if those pages
+    to determine which pages of a table must be scanned.  Normally, it
+    will skip pages that don't have any dead row versions even if those pages
     might still have row versions with old XID values.  Therefore, normal
-    scans won't succeed in freezing every row version in the table.
+    VACUUMs won't always freeze every old row version in the table.
     Periodically, VACUUM will perform an aggressive
     vacuum, skipping only those pages which contain neither dead rows nor
     any unfrozen XID or MXID values.