Skip to content

Commit 4995522

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 892da52 commit 4995522

File tree

1 file changed

+22
-9
lines changed

1 file changed

+22
-9
lines changed

doc/src/sgml/func.sgml

Lines changed: 22 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -17115,24 +17115,37 @@ SELECT setval('myseq', 42, false); <lineannotation>Next <function>nextval</fu
1711517115
<caution>
1711617116
<para>
1711717117
To avoid blocking concurrent transactions that obtain numbers from
17118-
the same sequence, a <function>nextval</function> operation is never
17119-
rolled back; that is, once a value has been fetched it is considered
17120-
used and will not be returned again. This is true even if the
17121-
surrounding transaction later aborts, or if the calling query ends
17122-
up not using the value. For example an <command>INSERT</command> with
17118+
the same sequence, the value obtained by <function>nextval</function>
17119+
is not reclaimed for re-use if the calling transaction later aborts.
17120+
This means that transaction aborts or database crashes can result in
17121+
gaps in the sequence of assigned values. That can happen without a
17122+
transaction abort, too. For example an <command>INSERT</command> with
1712317123
an <literal>ON CONFLICT</literal> clause will compute the to-be-inserted
1712417124
tuple, including doing any required <function>nextval</function>
1712517125
calls, before detecting any conflict that would cause it to follow
17126-
the <literal>ON CONFLICT</literal> rule instead. Such cases will leave
17127-
unused <quote>holes</quote> in the sequence of assigned values.
17126+
the <literal>ON CONFLICT</literal> rule instead.
1712817127
Thus, <productname>PostgreSQL</productname> sequence
1712917128
objects <emphasis>cannot be used to obtain <quote>gapless</quote>
1713017129
sequences</emphasis>.
1713117130
</para>
1713217131

1713317132
<para>
17134-
Likewise, any sequence state changes made by <function>setval</function>
17135-
are not undone if the transaction rolls back.
17133+
Likewise, sequence state changes made by <function>setval</function>
17134+
are immediately visible to other transactions, and are not undone if
17135+
the calling transaction rolls back.
17136+
</para>
17137+
17138+
<para>
17139+
If the database cluster crashes before committing a transaction
17140+
containing a <function>nextval</function>
17141+
or <function>setval</function> call, the sequence state change might
17142+
not have made its way to persistent storage, so that it is uncertain
17143+
whether the sequence will have its original or updated state after the
17144+
cluster restarts. This is harmless for usage of the sequence within
17145+
the database, since other effects of uncommitted transactions will not
17146+
be visible either. However, if you wish to use a sequence value for
17147+
persistent outside-the-database purposes, make sure that the
17148+
<function>nextval</function> call has been committed before doing so.
1713617149
</para>
1713717150
</caution>
1713817151

0 commit comments

Comments
 (0)