@@ -17645,24 +17645,37 @@ SELECT setval('myseq', 42, false); <lineannotation>Next <function>nextval</fu
17645
17645
<caution>
17646
17646
<para>
17647
17647
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
17653
17653
an <literal>ON CONFLICT</literal> clause will compute the to-be-inserted
17654
17654
tuple, including doing any required <function>nextval</function>
17655
17655
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.
17658
17657
Thus, <productname>PostgreSQL</productname> sequence
17659
17658
objects <emphasis>cannot be used to obtain <quote>gapless</quote>
17660
17659
sequences</emphasis>.
17661
17660
</para>
17662
17661
17663
17662
<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.
17666
17679
</para>
17667
17680
</caution>
17668
17681
0 commit comments