diff options
-rw-r--r-- | doc/src/sgml/mvcc.sgml | 20 | ||||
-rw-r--r-- | doc/src/sgml/ref/alter_table.sgml | 10 | ||||
-rw-r--r-- | doc/src/sgml/ref/truncate.sgml | 23 |
3 files changed, 35 insertions, 18 deletions
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml index 341351e46ff..040b29c1453 100644 --- a/doc/src/sgml/mvcc.sgml +++ b/doc/src/sgml/mvcc.sgml @@ -1181,6 +1181,26 @@ SELECT pg_advisory_lock(q.id) FROM </para> </sect1> + <sect1 id="mvcc-caveats"> + <title>Caveats</title> + + <para> + Some DDL commands, currently only <xref linkend="sql-truncate"> and the + table-rewriting forms of <xref linkend="sql-altertable">, are not + MVCC-safe. This means that after the truncation or rewrite commits, the + table will appear empty to concurrent transactions, if they are using a + snapshot taken before the DDL command committed. This will only be an + issue for a transaction that did not access the table in question + before the DDL command started — any transaction that has done so + would hold at least an <literal>ACCESS SHARE</literal> table lock, + which would block the DDL command until that transaction completes. + So these commands will not cause any apparent inconsistency in the + table contents for successive queries on the target table, but they + could cause visible inconsistency between the contents of the target + table and other tables in the database. + </para> + </sect1> + <sect1 id="locking-indexes"> <title>Locking and Indexes</title> diff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_table.sgml index 94343f88f6e..91f26f0d584 100644 --- a/doc/src/sgml/ref/alter_table.sgml +++ b/doc/src/sgml/ref/alter_table.sgml @@ -699,7 +699,8 @@ ALTER TABLE <replaceable class="PARAMETER">name</replaceable> <para> Adding a <literal>CHECK</> or <literal>NOT NULL</> constraint requires - scanning the table to verify that existing rows meet the constraint. + scanning the table to verify that existing rows meet the constraint, + but does not require a table rewrite. </para> <para> @@ -736,6 +737,13 @@ ALTER TABLE table ALTER COLUMN anycol TYPE anytype; </para> <para> + The rewriting forms of <command>ALTER TABLE</> are not MVCC-safe. + After a table rewrite, the table will appear empty to concurrent + transactions, if they are using a snapshot taken before the rewrite + occurred. See <xref linkend="mvcc-caveats"> for more details. + </para> + + <para> The <literal>USING</literal> option of <literal>SET DATA TYPE</> can actually specify any expression involving the old values of the row; that is, it can refer to other columns as well as the one being converted. This allows diff --git a/doc/src/sgml/ref/truncate.sgml b/doc/src/sgml/ref/truncate.sgml index 99202de5b49..2f1fafc6547 100644 --- a/doc/src/sgml/ref/truncate.sgml +++ b/doc/src/sgml/ref/truncate.sgml @@ -137,23 +137,12 @@ TRUNCATE [ TABLE ] [ ONLY ] <replaceable class="PARAMETER">name</replaceable> [ that were added due to cascading). </para> - <warning> - <para> - <command>TRUNCATE</> is not MVCC-safe (see <xref linkend="mvcc"> - 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 access the - truncated table before the truncation happened — any - transaction that has done so would hold at least an - <literal>ACCESS SHARE</literal> lock, which would block - <command>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 in the database. - </para> - </warning> + <para> + <command>TRUNCATE</> is not MVCC-safe. After truncation, the table will + appear empty to concurrent transactions, if they are using a snapshot + taken before the truncation occurred. + See <xref linkend="mvcc-caveats"> for more details. + </para> <para> <command>TRUNCATE</> is transaction-safe with respect to the data |