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

Commit3b6afdd

Browse files
author
Neil Conway
committed
Improvements to the SGML docs for TRUNCATE and CLUSTER.
1 parentbc8036f commit3b6afdd

File tree

2 files changed

+34
-31
lines changed

2 files changed

+34
-31
lines changed

‎doc/src/sgml/ref/cluster.sgml

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
<!--
2-
$PostgreSQL: pgsql/doc/src/sgml/ref/cluster.sgml,v 1.42 2007/04/08 02:07:35 tgl Exp $
2+
$PostgreSQL: pgsql/doc/src/sgml/ref/cluster.sgml,v 1.43 2007/05/11 19:40:07 neilc Exp $
33
PostgreSQL documentation
44
-->
55

@@ -45,7 +45,7 @@ CLUSTER
4545
not clustered. That is, no attempt is made to store new or
4646
updated rows according to their index order. (If one wishes, one can
4747
periodically recluster by issuing the command again. Also, setting
48-
the table's FILLFACTOR storage parameter to less than 100% can aid
48+
the table's<literal>FILLFACTOR</literal> storage parameter to less than 100% can aid
4949
in preserving cluster ordering during updates, since updated rows
5050
are preferentially kept on the same page.)
5151
</para>

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

Lines changed: 32 additions & 29 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
<!--
2-
$PostgreSQL: pgsql/doc/src/sgml/ref/truncate.sgml,v 1.23 2007/04/07 17:12:15 tgl Exp $
2+
$PostgreSQL: pgsql/doc/src/sgml/ref/truncate.sgml,v 1.24 2007/05/11 19:40:08 neilc Exp $
33
PostgreSQL documentation
44
-->
55

@@ -31,9 +31,9 @@ TRUNCATE [ TABLE ] <replaceable class="PARAMETER">name</replaceable> [, ...] [ C
3131
<command>TRUNCATE</command> quickly removes all rows from a set of
3232
tables. It has the same effect as an unqualified
3333
<command>DELETE</command> on each table, but since it does not actually
34-
scan the tables it is faster; furthermore it reclaims disk space
35-
immediately, rather than requiring a subsequentvacuum operation.
36-
This is most useful on large tables.
34+
scan the tables it is faster. Furthermore, it reclaims disk space
35+
immediately, rather than requiring a subsequent<command>VACUUM</command>
36+
operation.This is most useful on large tables.
3737
</para>
3838
</refsect1>
3939

@@ -86,35 +86,38 @@ TRUNCATE [ TABLE ] <replaceable class="PARAMETER">name</replaceable> [, ...] [ C
8686
in the same command. Checking validity in such cases would require table
8787
scans, and the whole point is not to do one. The <literal>CASCADE</>
8888
option can be used to automatically include all dependent tables &mdash;
89-
but be very careful when using this option, else you might lose data you
89+
but be very careful when using this option,orelse you might lose data you
9090
did not intend to!
9191
</para>
9292

9393
<para>
94-
<command>TRUNCATE</> will not run anyuser-defined<literal>ON
95-
DELETE</literal>triggers that might exist for the tables.
94+
<command>TRUNCATE</> will not run any <literal>ON DELETE</literal>
95+
triggers that might exist for the tables.
9696
</para>
9797

98-
<para>
99-
<command>TRUNCATE</> is not MVCC-safe (see <xref linkend="mvcc">
100-
for general information about MVCC). After truncation, the table
101-
will appear empty to all concurrent transactions, even if they are
102-
using a snapshot taken before the truncation occurred. This will
103-
only be an issue for a transaction that did not touch the table
104-
before the truncation started &mdash; any transaction that has done
105-
so would hold at least <literal>ACCESS SHARE</literal> lock,
106-
which would block
107-
<command>TRUNCATE</> until that transaction completes. So
108-
truncation will not cause any apparent inconsistency in the table
109-
contents for successive queries on the same table, but it could
110-
cause visible inconsistency between the contents of the
111-
truncated table and other tables.
112-
</para>
113-
114-
<para>
115-
<command>TRUNCATE</> is transaction-safe, however: the truncation
116-
will roll back if the surrounding transaction does not commit.
117-
</para>
98+
<warning>
99+
<para>
100+
<command>TRUNCATE</> is not MVCC-safe (see <xref linkend="mvcc">
101+
for general information about MVCC). After truncation, the table
102+
will appear empty to all concurrent transactions, even if they
103+
are using a snapshot taken before the truncation occurred. This
104+
will only be an issue for a transaction that did not access the
105+
truncated table before the truncation happened &mdash; any
106+
transaction that has done so would hold at least an
107+
<literal>ACCESS SHARE</literal> lock, which would block
108+
<command>TRUNCATE</> until that transaction completes. So
109+
truncation will not cause any apparent inconsistency in the table
110+
contents for successive queries on the same table, but it could
111+
cause visible inconsistency between the contents of the truncated
112+
table and other tables in the database.
113+
</para>
114+
115+
<para>
116+
<command>TRUNCATE</> is transaction-safe, however: the truncation
117+
will be safely rolled back if the surrounding transaction does not
118+
commit.
119+
</para>
120+
</warning>
118121
</refsect1>
119122

120123
<refsect1>
@@ -124,13 +127,13 @@ TRUNCATE [ TABLE ] <replaceable class="PARAMETER">name</replaceable> [, ...] [ C
124127
Truncate the tables <literal>bigtable</literal> and <literal>fattable</literal>:
125128

126129
<programlisting>
127-
TRUNCATETABLEbigtable, fattable;
130+
TRUNCATE bigtable, fattable;
128131
</programlisting>
129132
</para>
130133

131134
<para>
132135
Truncate the table <literal>othertable</literal>, and cascade to any tables
133-
thatare referencing <literal>othertable</literal> via foreign-key
136+
thatreference <literal>othertable</literal> via foreign-key
134137
constraints:
135138

136139
<programlisting>

0 commit comments

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