Skip to content

Commit 1bfe97e

Browse files
committed
Rewrite the warning about non-transaction-safety of TRUNCATE ... RESTART
IDENTITY to be more explicit about the possible hazards. Per gripe from Neil and subsequent discussion. Eventually we may be able to get rid of this warning, but for now it had better be there.
1 parent 265f19d commit 1bfe97e

File tree

1 file changed

+21
-6
lines changed

1 file changed

+21
-6
lines changed

doc/src/sgml/ref/truncate.sgml

Lines changed: 21 additions & 6 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.26 2008/05/16 23:36:04 tgl Exp $
2+
$PostgreSQL: pgsql/doc/src/sgml/ref/truncate.sgml,v 1.27 2008/05/17 23:36:27 tgl Exp $
33
PostgreSQL documentation
44
-->
55

@@ -151,11 +151,26 @@ TRUNCATE [ TABLE ] <replaceable class="PARAMETER">name</replaceable> [, ... ]
151151
<para>
152152
Any <command>ALTER SEQUENCE RESTART</> operations performed as a
153153
consequence of using the <literal>RESTART IDENTITY</> option are
154-
nontransactional and will not be rolled back. To minimize risk,
155-
these operations are performed only after all the rest of
156-
<command>TRUNCATE</>'s work is done. In practice this will only
157-
be an issue if <command>TRUNCATE</> is performed inside a
158-
transaction block that is aborted afterwards.
154+
nontransactional and will not be rolled back on failure. To minimize
155+
the risk, these operations are performed only after all the rest of
156+
<command>TRUNCATE</>'s work is done. However, there is still a risk
157+
if <command>TRUNCATE</> is performed inside a transaction block that is
158+
aborted afterwards. For example, consider
159+
160+
<programlisting>
161+
BEGIN;
162+
TRUNCATE TABLE foo RESTART IDENTITY;
163+
COPY foo FROM ...;
164+
COMMIT;
165+
</programlisting>
166+
167+
If the <command>COPY</> fails partway through, the table data
168+
rolls back correctly, but the sequences will be left with values
169+
that are probably smaller than they had before, possibly leading
170+
to duplicate-key failures or other problems in later transactions.
171+
If this is likely to be a problem, it's best to avoid using
172+
<literal>RESTART IDENTITY</>, and accept that the new contents of
173+
the table will have higher serial numbers than the old.
159174
</para>
160175
</warning>
161176
</refsect1>

0 commit comments

Comments
 (0)