@@ -17300,24 +17300,37 @@ SELECT setval('myseq', 42, false); <lineannotation>Next <function>nextval</fu
1730017300 <caution>
1730117301 <para>
1730217302 To avoid blocking concurrent transactions that obtain numbers from
17303- the same sequence,a <function>nextval</function> operation is never
17304- rolled back; that is, once a value has been fetched it is considered
17305- used and will not be returned again. This is true even if the
17306- surrounding transaction later aborts, or if the calling query ends
17307- up not using the value . For example an <command>INSERT</command> with
17303+ the same sequence,the value obtained by <function>nextval</function>
17304+ is not reclaimed for re-use if the calling transaction later aborts.
17305+ This means that transaction aborts or database crashes can result in
17306+ gaps in the sequence of assigned values. That can happen without a
17307+ transaction abort, too . For example an <command>INSERT</command> with
1730817308 an <literal>ON CONFLICT</literal> clause will compute the to-be-inserted
1730917309 tuple, including doing any required <function>nextval</function>
1731017310 calls, before detecting any conflict that would cause it to follow
17311- the <literal>ON CONFLICT</literal> rule instead. Such cases will leave
17312- unused <quote>holes</quote> in the sequence of assigned values.
17311+ the <literal>ON CONFLICT</literal> rule instead.
1731317312 Thus, <productname>PostgreSQL</productname> sequence
1731417313 objects <emphasis>cannot be used to obtain <quote>gapless</quote>
1731517314 sequences</emphasis>.
1731617315 </para>
1731717316
1731817317 <para>
17319- Likewise, any sequence state changes made by <function>setval</function>
17320- are not undone if the transaction rolls back.
17318+ Likewise, sequence state changes made by <function>setval</function>
17319+ are immediately visible to other transactions, and are not undone if
17320+ the calling transaction rolls back.
17321+ </para>
17322+
17323+ <para>
17324+ If the database cluster crashes before committing a transaction
17325+ containing a <function>nextval</function>
17326+ or <function>setval</function> call, the sequence state change might
17327+ not have made its way to persistent storage, so that it is uncertain
17328+ whether the sequence will have its original or updated state after the
17329+ cluster restarts. This is harmless for usage of the sequence within
17330+ the database, since other effects of uncommitted transactions will not
17331+ be visible either. However, if you wish to use a sequence value for
17332+ persistent outside-the-database purposes, make sure that the
17333+ <function>nextval</function> call has been committed before doing so.
1732117334 </para>
1732217335 </caution>
1732317336