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