Обсуждение: BUG #17112: Sequence number is not restored when the stored procedure ends abnormally

The following bug has been logged on the website:

Bug reference:      17112
Logged by:          Yuetsuro Kobayashi
Email address:      inconvenience.notice@gmail.com
PostgreSQL version: 13.3
Operating system:   Windows 10 Pro
Description:

When process was abnormal ends by a stored procedure processing problem, the
table processing is restored, but sequence number remains incremented and is
not restored.

Hello

Exactly as expected. It's intentional and not a bug. Sequences are guaranteed to be unique.

regards, Sergei

Sergei:

On Fri, Jul 16, 2021 at 9:59 AM Sergei Kornilov <sk@zsrv.org> wrote:
> Exactly as expected. It's intentional and not a bug. Sequences are guaranteed to be unique.

I would add "but NOT guaranteed to be continuous ( gapless ) or
strictly growing among different connections", which seems to be the
behaviour OP is complaining about.

For the OP:

This means you can get 1,3,5 ( not continuous ) or, if using two
connections, A and B, you can get ( time ordered ) 1 in a, 3 in b, 2
in A, 4 in b,....( A backend/connection can grab a chunk and serve
numbers from it to its clients, chunks will not overlap, this
behaviour can be observed if A and B grab two numbers chunks  )

It also means sequences can not be used for things like bill numbers
in spain ( which must be growing and gapless ), in case you are using
them for something like that.  It is done this way to improve
concurrency / speed for their intended usage of generating synthetic
PKs and similar stuff ( if you do it strictlly growing, like my bill
numbers stuff, once someone gets a number everyone else needing them
must be stopped until it commits or rolls back ).

Francisco Olarte.