@@ -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