</para>
<para>
Unexpected results might be obtained if a <replaceable
class="parameter">cache</replaceable> setting greater than one is
used for a sequence object that will be used concurrently by
multiple sessions. Each session will allocate and cache successive
sequence values during one access to the sequence object and
increase the sequence object's <literal>last_value</literal> accordingly.
Then, the next <replaceable class="parameter">cache</replaceable>-1
uses of <function>nextval</function> within that session simply return the
preallocated values without touching the sequence object. So, any
numbers allocated but not used within a session will be lost when
that session ends, resulting in <quote>holes</quote> in the
sequence.
</para>
<para>
Furthermore, although multiple sessions are guaranteed to allocate
distinct sequence values, the values might be generated out of
sequence when all the sessions are considered. For example, with
a <replaceable class="parameter">cache</replaceable> setting of 10,
session A might reserve values 1..10 and return
<function>nextval</function>=1, then session B might reserve values
11..20 and return <function>nextval</function>=11 before session A
has generated <function>nextval</function>=2. Thus, with a
<replaceable class="parameter">cache</replaceable> setting of one
it is safe to assume that <function>nextval</function> values are generated
sequentially; with a <replaceable
class="parameter">cache</replaceable> setting greater than one you
should only assume that the <function>nextval</function> values are all
distinct, not that they are generated purely sequentially. Also,
<literal>last_value</literal> will reflect the latest value reserved by
any session, whether or not it has yet been returned by
<function>nextval</function>.
</para>
<para>
Another consideration is that a <function>setval</function> executed on
such a sequence will not be noticed by other sessions until they
have used up any preallocated values they have cached.
</para>
</refsect1>
<refsect1>
<title>Examples</title>
<para>
Create an ascending sequence called <literal>serial</literal>, starting at 101:
<programlisting>
CREATE SEQUENCE serial START 101;
</programlisting>
</para>
<para>
Select the next number from this sequence:
<programlisting>
SELECT nextval('serial');
nextval
---------
101
</programlisting>
</para>
<para>
Select the next number from this sequence:
<programlisting>
SELECT nextval('serial');
nextval
---------
102
</programlisting>
</para>
<para>
Use this sequence in an <command>INSERT</command> command:
<programlisting>
INSERT INTO distributors VALUES (nextval('serial'), 'nothing');
</programlisting>
</para>
<para>
Update the sequence value after a <command>COPY FROM</command>:
<programlisting>
BEGIN;
COPY distributors FROM 'input_file';
SELECT setval('serial', max(id)) FROM distributors;
END;
</programlisting></para>
</refsect1>
<refsect1>
<title>Compatibility</title>
<para>
<command>CREATE SEQUENCE</command> conforms to the <acronym>SQL</acronym>
standard, with the following exceptions:
<itemizedlist>
<listitem>
<para>
Obtaining the next value is done using the <function>nextval()</function>
function instead of the standard's <command>NEXT VALUE FOR</command>
expression.
</para>
</listitem>
<listitem>
<para>
The <literal>OWNED BY</literal> clause is a <productname>PostgreSQL</productname>
extension.
</para>
</listitem>
</itemizedlist></para>
</refsect1>
<refsect1>
<title>See Also</title>
<simplelist type="inline">
<member><xref linkend="sql-altersequence"/></member>
<member><xref linkend="sql-dropsequence"/></member>
</simplelist>
</refsect1>
</refentry>