Home Explore Blog CI



postgresql

5th chunk of `doc/src/sgml/ref/create_sequence.sgml`
7f22670f53311f3aac2bb344770451e3bfbaf6dd20bed7bb0000000100000f58
 </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>

Title: CREATE SEQUENCE: Caching, Examples, and Compatibility
Summary
This section discusses the implications of caching sequence values in concurrent sessions, explaining how it can lead to out-of-order sequence generation and how setval might not be immediately visible to other sessions. It then provides examples of creating and using sequences with nextval in INSERT statements, and updating sequences after COPY FROM operations. Finally, it details compatibility with the SQL standard, noting the use of nextval() instead of NEXT VALUE FOR and the PostgreSQL-specific OWNED BY clause.