summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--doc/src/sgml/mvcc.sgml20
-rw-r--r--doc/src/sgml/ref/alter_table.sgml10
-rw-r--r--doc/src/sgml/ref/truncate.sgml23
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 &mdash; 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 &mdash; 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