Add note that TRUNCATE is not MVCC-safe.

diff --git a/doc/src/sgml/ref/truncate.sgml b/doc/src/sgml/ref/truncate.sgml
index 79ed75b4999713919772d692e01755cb04a02692..271d16af03e5082d590fb1c9d5ef9bb561093a49 100644 (file)
--- a/doc/src/sgml/ref/truncate.sgml
+++ b/doc/src/sgml/ref/truncate.sgml
@@ -1,5 +1,5 @@
 
 
@@ -31,7 +31,9 @@ TRUNCATE [ TABLE ] name [, ...] [ C
    TRUNCATE quickly removes all rows from a set of
    tables. It has the same effect as an unqualified
    DELETE on each table, but since it does not actually
-   scan the tables it is faster. This is most useful on large tables.
+   scan the tables it is faster; furthermore it reclaims disk space
+   immediately, rather than requiring a subsequent vacuum operation.
+   This is most useful on large tables.
   
  
   
@@ -92,6 +94,27 @@ TRUNCATE [ TABLE ] name [, ...] [ C
    TRUNCATE will not run any user-defined ON
    DELETE triggers that might exist for the tables.
   
+
+  
+   TRUNCATE is not MVCC-safe (see 
+   for general information about MVCC).  After truncation, the table
+   will appear empty to all concurrent transactions, even if they are
+   using a snapshot taken before the truncation occurred.  This will
+   only be an issue for a transaction that did not touch the table
+   before the truncation started — any transaction that has done
+   so would hold at least ACCESS SHARE lock,
+   which would block
+   TRUNCATE until that transaction completes.  So
+   truncation will not cause any apparent inconsistency in the table
+   contents for successive queries on the same table, but it could
+   cause visible inconsistency between the contents of the
+   truncated table and other tables.
+  
+
+  
+   TRUNCATE is transaction-safe, however: the truncation
+   will roll back if the surrounding transaction does not commit.
+