Skip to content

Commit 4ac452e

Browse files
committed
Doc: improve documentation about nextval()/setval().
Clarify that the results of nextval and setval are not guaranteed persistent until the calling transaction commits. Some people seem to have drawn the opposite conclusion from the statement that these functions are never rolled back, so re-word to avoid saying it quite that way. Discussion: https://postgr.es/m/CAKU4AWohO=NfM-4KiZWvdc+z3c1C9FrUBR6xnReFJ6sfy0i=Lw@mail.gmail.com
1 parent 373e552 commit 4ac452e

File tree

1 file changed

+22
-9
lines changed

1 file changed

+22
-9
lines changed

doc/src/sgml/func.sgml

+22-9
Original file line numberDiff line numberDiff line change
@@ -17645,24 +17645,37 @@ SELECT setval('myseq', 42, false); <lineannotation>Next <function>nextval</fu
1764517645
<caution>
1764617646
<para>
1764717647
To avoid blocking concurrent transactions that obtain numbers from
17648-
the same sequence, a <function>nextval</function> operation is never
17649-
rolled back; that is, once a value has been fetched it is considered
17650-
used and will not be returned again. This is true even if the
17651-
surrounding transaction later aborts, or if the calling query ends
17652-
up not using the value. For example an <command>INSERT</command> with
17648+
the same sequence, the value obtained by <function>nextval</function>
17649+
is not reclaimed for re-use if the calling transaction later aborts.
17650+
This means that transaction aborts or database crashes can result in
17651+
gaps in the sequence of assigned values. That can happen without a
17652+
transaction abort, too. For example an <command>INSERT</command> with
1765317653
an <literal>ON CONFLICT</literal> clause will compute the to-be-inserted
1765417654
tuple, including doing any required <function>nextval</function>
1765517655
calls, before detecting any conflict that would cause it to follow
17656-
the <literal>ON CONFLICT</literal> rule instead. Such cases will leave
17657-
unused <quote>holes</quote> in the sequence of assigned values.
17656+
the <literal>ON CONFLICT</literal> rule instead.
1765817657
Thus, <productname>PostgreSQL</productname> sequence
1765917658
objects <emphasis>cannot be used to obtain <quote>gapless</quote>
1766017659
sequences</emphasis>.
1766117660
</para>
1766217661

1766317662
<para>
17664-
Likewise, any sequence state changes made by <function>setval</function>
17665-
are not undone if the transaction rolls back.
17663+
Likewise, sequence state changes made by <function>setval</function>
17664+
are immediately visible to other transactions, and are not undone if
17665+
the calling transaction rolls back.
17666+
</para>
17667+
17668+
<para>
17669+
If the database cluster crashes before committing a transaction
17670+
containing a <function>nextval</function>
17671+
or <function>setval</function> call, the sequence state change might
17672+
not have made its way to persistent storage, so that it is uncertain
17673+
whether the sequence will have its original or updated state after the
17674+
cluster restarts. This is harmless for usage of the sequence within
17675+
the database, since other effects of uncommitted transactions will not
17676+
be visible either. However, if you wish to use a sequence value for
17677+
persistent outside-the-database purposes, make sure that the
17678+
<function>nextval</function> call has been committed before doing so.
1766617679
</para>
1766717680
</caution>
1766817681

0 commit comments

Comments
 (0)