c8h4/postgresql
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity

Warn more vigorously about the non-transactional behavior of sequences.

Browse source 
Craig Ringer, edited fairly heavily by me
This commit is contained in:
Robert Haas 2012-08-06 15:18:00 -04:00
parent f5f8e7169f
commit 95282d3522
2 changed files with 42 additions and 20 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
doc/src/sgml/datatype.sgml
View file

@ -829,6 +829,20 @@ ALTER SEQUENCE <replaceable class="parameter">tablename</replaceable>_<replaceab
the column, so that it will be dropped if the column or table is dropped.
</para>
<note>
<para>
Because <type>smallserial</type>, <type>serial</type> and
<type>bigserial</type> are implemented usings sequences, there may
be "holes" or gaps in the sequence of values which appears in the
column, even if no rows are ever deleted. This is a value allocated
from the sequence is still "used up" even if a row containing that
value is never successfully inserted into the table column. This
may happen, for example, if the inserting transaction rolls back.
See <literal>nextval()</literal> in <xref linkend="functions-sequence">
for details.
</para>
</note>
<note>
<para>
Prior to <productname>PostgreSQL</productname> 7.3, <type>serial</type>

48
doc/src/sgml/func.sgml
View file

@ -9820,6 +9820,27 @@ nextval('foo'::text) <lineannotation><literal>foo</literal> is looked up at
execute <function>nextval</function> concurrently, each will safely receive
a distinct sequence value.
</para>
<para>
If a sequence object has been created with default parameters,
successive <function>nextval</function> calls will return successive
values beginning with 1. Other behaviors can be obtained by using
special parameters in the <xref linkend="sql-createsequence"> command;
see its command reference page for more information.
</para>
<important>
<para>
To avoid blocking concurrent transactions that obtain numbers from the
same sequence, a <function>nextval</function> operation is never
rolled back; that is, once a value has been fetched it is considered
used, even if the transaction that did the
<function>nextval</function> later aborts. This means that aborted
transactions might leave unused <quote>holes</quote> in the sequence
of assigned values.
</para>
</important>
</listitem>
</varlistentry>
@ -9883,31 +9904,18 @@ SELECT setval('foo', 42, false); <lineannotation>Next <function>nextval</> wi
The result returned by <function>setval</function> is just the value of its
second argument.
</para>
<important>
<para>
Because sequences are non-transactional, changes made by
<function>setval</function> are not undone if the transaction rolls
back.
</para>
</important>
</listitem>
</varlistentry>
</variablelist>
</para>
<para>
If a sequence object has been created with default parameters,
successive <function>nextval</function> calls will return successive values
beginning with 1. Other behaviors can be obtained by using
special parameters in the <xref linkend="sql-createsequence"> command;
see its command reference page for more information.
</para>
<important>
<para>
To avoid blocking concurrent transactions that obtain numbers from the
same sequence, a <function>nextval</function> operation is never rolled back;
that is, once a value has been fetched it is considered used, even if the
transaction that did the <function>nextval</function> later aborts. This means
that aborted transactions might leave unused <quote>holes</quote> in the
sequence of assigned values. <function>setval</function> operations are never
rolled back, either.
</para>
</important>
</sect1>