Re: [BUGS] Bug #613: Sequence values fall back to previously chec
От | Mikheev, Vadim |
---|---|
Тема | Re: [BUGS] Bug #613: Sequence values fall back to previously chec |
Дата | |
Msg-id | 3705826352029646A3E91C53F7189E325184DA@sectorbase2.sectorbase.com обсуждение исходный текст |
Ответы |
Re: [BUGS] Bug #613: Sequence values fall back to previously chec
|
Список | pgsql-hackers |
> > This isn't an issue for a SELECT nextval() standing on > > its own AFAIK the result will not be transmitted to the > > client until after the commit happens. But it would be > > an issue for a select executed inside a transaction > > block (begin/commit). > > The behavior of SELECT nextval() should not be conditional > on being in or out of a transaction block. And it's not. But behaviour of application *must* be conditional on was transaction committed or not. What's the problem for application that need nextval() for external (out-of-database) purposes to use sequence values only after transaction commit? What's *wrong* for such application to behave the same way as when dealing with other database objects which are under transaction control (eg only after commit you can report to user that $100 was successfully added to his/her account)? --- I agree that if nextval-s were only "write" actions in transaction and they made some XLogInsert-s then WAL must be flushed at commit time. But that's it. Was this fixed? Very easy. Vadim
В списке pgsql-hackers по дате отправления: