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

Commitff2ee45

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 parentc9b7273 commitff2ee45

File tree

3 files changed

+52
-38
lines changed

3 files changed

+52
-38
lines changed

‎doc/src/sgml/mvcc.sgml

Lines changed: 32 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -708,20 +708,6 @@ ERROR: could not serialize access due to read/write dependencies among transact
708708
</listitem>
709709
</itemizedlist>
710710
</para>
711-
712-
<warning>
713-
<para>
714-
Support for the Serializable transaction isolation level has not yet
715-
been added to Hot Standby replication targets (described in
716-
<xref linkend="hot-standby">). The strictest isolation level currently
717-
supported in hot standby mode is Repeatable Read. While performing all
718-
permanent database writes within Serializable transactions on the
719-
master will ensure that all standbys will eventually reach a consistent
720-
state, a Repeatable Read transaction run on the standby can sometimes
721-
see a transient state which is inconsistent with any serial execution
722-
of serializable transactions on the master.
723-
</para>
724-
</warning>
725711
</sect2>
726712
</sect1>
727713

@@ -1618,6 +1604,38 @@ SELECT pg_advisory_lock(q.id) FROM
16181604
</sect2>
16191605
</sect1>
16201606

1607+
<sect1 id="mvcc-caveats">
1608+
<title>Caveats</title>
1609+
1610+
<para>
1611+
Some DDL commands, currently only <xref linkend="sql-truncate"> and the
1612+
table-rewriting forms of <xref linkend="sql-altertable">, are not
1613+
MVCC-safe. This means that after the truncation or rewrite commits, the
1614+
table will appear empty to concurrent transactions, if they are using a
1615+
snapshot taken before the DDL command committed. This will only be an
1616+
issue for a transaction that did not access the table in question
1617+
before the DDL command started &mdash; any transaction that has done so
1618+
would hold at least an <literal>ACCESS SHARE</literal> table lock,
1619+
which would block the DDL command until that transaction completes.
1620+
So these commands will not cause any apparent inconsistency in the
1621+
table contents for successive queries on the target table, but they
1622+
could cause visible inconsistency between the contents of the target
1623+
table and other tables in the database.
1624+
</para>
1625+
1626+
<para>
1627+
Support for the Serializable transaction isolation level has not yet
1628+
been added to Hot Standby replication targets (described in
1629+
<xref linkend="hot-standby">). The strictest isolation level currently
1630+
supported in hot standby mode is Repeatable Read. While performing all
1631+
permanent database writes within Serializable transactions on the
1632+
master will ensure that all standbys will eventually reach a consistent
1633+
state, a Repeatable Read transaction run on the standby can sometimes
1634+
see a transient state that is inconsistent with any serial execution
1635+
of the transactions on the master.
1636+
</para>
1637+
</sect1>
1638+
16211639
<sect1 id="locking-indexes">
16221640
<title>Locking and Indexes</title>
16231641

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

Lines changed: 14 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -623,7 +623,7 @@ ALTER TABLE ALL IN TABLESPACE <replaceable class="PARAMETER">name</replaceable>
623623
This form changes the information which is written to the write-ahead log
624624
to identify rows which are updated or deleted. This option has no effect
625625
except when logical replication is in use. <literal>DEFAULT</>
626-
(the default for non-system tables) records the
626+
(the default for non-system tables) records the
627627
old values of the columns of the primary key, if any. <literal>USING INDEX</>
628628
records the old values of the columns covered by the named index, which
629629
must be unique, not partial, not deferrable, and include only columns marked
@@ -915,7 +915,8 @@ ALTER TABLE ALL IN TABLESPACE <replaceable class="PARAMETER">name</replaceable>
915915

916916
<para>
917917
Adding a <literal>CHECK</> or <literal>NOT NULL</> constraint requires
918-
scanning the table to verify that existing rows meet the constraint.
918+
scanning the table to verify that existing rows meet the constraint,
919+
but does not require a table rewrite.
919920
</para>
920921

921922
<para>
@@ -937,11 +938,17 @@ ALTER TABLE ALL IN TABLESPACE <replaceable class="PARAMETER">name</replaceable>
937938
</para>
938939

939940
<para>
940-
To force an immediate rewrite of the table, you can use
941-
<link linkend="SQL-VACUUM">VACUUM FULL</>, <xref linkend="SQL-CLUSTER">
942-
or one of the forms of ALTER TABLE that forces a rewrite. This results in
943-
no semantically-visible change in the table, but gets rid of
944-
no-longer-useful data.
941+
To force immediate reclamation of space occupied by a dropped column,
942+
you can execute one of the forms of <command>ALTER TABLE</> that
943+
performs a rewrite of the whole table. This results in reconstructing
944+
each row with the dropped column replaced by a null value.
945+
</para>
946+
947+
<para>
948+
The rewriting forms of <command>ALTER TABLE</> are not MVCC-safe.
949+
After a table rewrite, the table will appear empty to concurrent
950+
transactions, if they are using a snapshot taken before the rewrite
951+
occurred. See <xref linkend="mvcc-caveats"> for more details.
945952
</para>
946953

947954
<para>

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

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

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

161150
<para>
162151
<command>TRUNCATE</> is transaction-safe with respect to the data

0 commit comments

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