Andres Freund <and...@2ndquadrant.com> writes:
> Thats caused by the fact that you didn't do anything that forces a WAL
> flush since you didn't do any inserts or such. If you would do any
> DML in the nextval() calling transaction this shouldn't happen (unless
> you use synchronous_commit=off).
> Now, there's a legitimate argument to be made that returning the
> sequence value to the user kinda persists it. On the other hand, at
> least in the first example you haven't even committed the transaction so
> there's nothing that could flush the transaction unless we we would
> *always* flush nextval() immediately if needs to get new values which
> doesn't seem reasonable.
I believe we've gone around on this before and decided to leave it
as-is. The thinking is that any realistic use-case would involve
storing the nextval result into some table somewhere, so that additional
WAL and a commit record would be generated.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
