Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitec2bc39

Browse files
committed
Improve documentation about MVCC-unsafe utility commands.
The table-rewriting forms of ALTER TABLE are MVCC-unsafe, in much the sameway as TRUNCATE, because they replace all rows of the table with newly-maderows with a new xmin. (Ideally, concurrent transactions with old snapshotswould continue to see the old table contents, but the data is not thereanymore --- and if it were there, it would be inconsistent with the table'supdated rowtype, so there would be serious implementation problems to fix.)This was nowhere documented though, and the problem was only documented forTRUNCATE in a note in the TRUNCATE reference page. Create a new "Caveats"section in the MVCC chapter that can be home to this and other limitationson serializable consistency.In passing, fix a mistaken statement that VACUUM and CLUSTER would reclaimspace occupied by a dropped column. They don't reconstruct existing tuplesso they couldn't do that.Back-patch to all supported branches.
1 parent9d6af73 commitec2bc39

File tree

3 files changed

+35
-18
lines changed

3 files changed

+35
-18
lines changed

‎doc/src/sgml/mvcc.sgml

Lines changed: 20 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1181,6 +1181,26 @@ SELECT pg_advisory_lock(q.id) FROM
11811181
</para>
11821182
</sect1>
11831183

1184+
<sect1 id="mvcc-caveats">
1185+
<title>Caveats</title>
1186+
1187+
<para>
1188+
Some DDL commands, currently only <xref linkend="sql-truncate"> and the
1189+
table-rewriting forms of <xref linkend="sql-altertable">, are not
1190+
MVCC-safe. This means that after the truncation or rewrite commits, the
1191+
table will appear empty to concurrent transactions, if they are using a
1192+
snapshot taken before the DDL command committed. This will only be an
1193+
issue for a transaction that did not access the table in question
1194+
before the DDL command started &mdash; any transaction that has done so
1195+
would hold at least an <literal>ACCESS SHARE</literal> table lock,
1196+
which would block the DDL command until that transaction completes.
1197+
So these commands will not cause any apparent inconsistency in the
1198+
table contents for successive queries on the target table, but they
1199+
could cause visible inconsistency between the contents of the target
1200+
table and other tables in the database.
1201+
</para>
1202+
</sect1>
1203+
11841204
<sect1 id="locking-indexes">
11851205
<title>Locking and Indexes</title>
11861206

‎doc/src/sgml/ref/alter_table.sgml

Lines changed: 9 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -699,7 +699,8 @@ ALTER TABLE <replaceable class="PARAMETER">name</replaceable>
699699

700700
<para>
701701
Adding a <literal>CHECK</> or <literal>NOT NULL</> constraint requires
702-
scanning the table to verify that existing rows meet the constraint.
702+
scanning the table to verify that existing rows meet the constraint,
703+
but does not require a table rewrite.
703704
</para>
704705

705706
<para>
@@ -735,6 +736,13 @@ ALTER TABLE table ALTER COLUMN anycol TYPE anytype;
735736
data.
736737
</para>
737738

739+
<para>
740+
The rewriting forms of <command>ALTER TABLE</> are not MVCC-safe.
741+
After a table rewrite, the table will appear empty to concurrent
742+
transactions, if they are using a snapshot taken before the rewrite
743+
occurred. See <xref linkend="mvcc-caveats"> for more details.
744+
</para>
745+
738746
<para>
739747
The <literal>USING</literal> option of <literal>SET DATA TYPE</> can actually
740748
specify any expression involving the old values of the row; that is, it

‎doc/src/sgml/ref/truncate.sgml

Lines changed: 6 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -137,23 +137,12 @@ TRUNCATE [ TABLE ] [ ONLY ] <replaceable class="PARAMETER">name</replaceable> [
137137
that were added due to cascading).
138138
</para>
139139

140-
<warning>
141-
<para>
142-
<command>TRUNCATE</> is not MVCC-safe (see <xref linkend="mvcc">
143-
for general information about MVCC). After truncation, the table
144-
will appear empty to all concurrent transactions, even if they
145-
are using a snapshot taken before the truncation occurred. This
146-
will only be an issue for a transaction that did not access the
147-
truncated table before the truncation happened &mdash; any
148-
transaction that has done so would hold at least an
149-
<literal>ACCESS SHARE</literal> lock, which would block
150-
<command>TRUNCATE</> until that transaction completes. So
151-
truncation will not cause any apparent inconsistency in the table
152-
contents for successive queries on the same table, but it could
153-
cause visible inconsistency between the contents of the truncated
154-
table and other tables in the database.
155-
</para>
156-
</warning>
140+
<para>
141+
<command>TRUNCATE</> is not MVCC-safe. After truncation, the table will
142+
appear empty to concurrent transactions, if they are using a snapshot
143+
taken before the truncation occurred.
144+
See <xref linkend="mvcc-caveats"> for more details.
145+
</para>
157146

158147
<para>
159148
<command>TRUNCATE</> is transaction-safe with respect to the data

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp