> > 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.
pgsql-hackers by date
|Next:||From: Kyle||Date: 2002-03-15 00:52:36|
|Subject: Re: Client/Server compression? |
|Previous:||From: Tom Lane||Date: 2002-03-15 00:03:45|
|Subject: Re: [SQL] Syslog |
pgsql-bugs by date
|Next:||From: 'Ben Grimm'||Date: 2002-03-15 01:55:23|
|Subject: Re: Bug #613: Sequence values fall back to previously chec|
|Previous:||From: Tom Lane||Date: 2002-03-14 23:58:04|
|Subject: Re: Bug #613: Sequence values fall back to previously chec |