Re: BUG #17112: Sequence number is not restored when the stored procedure ends abnormally

Sergei:

On Fri, Jul 16, 2021 at 9:59 AM Sergei Kornilov <sk(at)zsrv(dot)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.