From d7e2de6629e082322429726618e1dd75ea423cdc Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sat, 7 Apr 2007 17:12:15 +0000 Subject: [PATCH] Add note that TRUNCATE is not MVCC-safe. --- doc/src/sgml/ref/truncate.sgml | 27 +++++++++++++++++++++++++-- 1 file changed, 25 insertions(+), 2 deletions(-) diff --git a/doc/src/sgml/ref/truncate.sgml b/doc/src/sgml/ref/truncate.sgml index 79ed75b499..271d16af03 100644 --- 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. + -- 2.40.0