> > 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
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
