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

Поиск
Список
Период
Сортировка
От Francisco Olarte
Тема Re: BUG #17112: Sequence number is not restored when the stored procedure ends abnormally
Дата
Msg-id CA+bJJbxhKdAX9sZDsMoJyPM1bN-mcy0mpVxMg3g13LF0c7S4pg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #17112: Sequence number is not restored when the stored procedure ends abnormally  (Sergei Kornilov <sk@zsrv.org>)
Список pgsql-bugs
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.



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Japin Li
Дата:
Сообщение: Re: BUG #17111: Database created, cannot be created, but reported as inexist
Следующее
От: Japin Li
Дата:
Сообщение: Re: BUG #17111: Database created, cannot be created, but reported as inexist