Hi Frank,
I believe this is by design. See the bottom of the documentation on sequences where it states ;-
"
Important: To avoid blocking concurrent transactions that obtain numbers from the same sequence, a
nextval operation is never rolled back; that is, once a value has been fetched it is considered used, even if the transaction that did the
nextval later aborts. This means that aborted transactions might leave unused
"holes" in the sequence of assigned values.
setval operations are never rolled back, either."
http://www.postgresql.org/docs/9.1/static/functions-sequence.html If you really want to reset the sequence, I think you would have to call SELECT SETVAL(.....) at the point you request the roll-back.
Regards
Andrew
On 02/08/12 16:08, Frank Lanitz wrote:
Hi folks,
I did a test with transactions and wondered about an behavior I didn't
expected. At http://pastebin.geany.org/bYQNo/raw/ I posted a complete
backlog for.
To make it short: I created a table with a serial and started a
transactions. After this I was inserting values into the table but did a
rollback. However. The sequence of the serial filed has been incremented
by 1 on each insert (which is fine), but wasn't reset after rollback of
transaction.
Documentation stats:
"If, partway through the transaction, we decide we do not wantto commit
(perhaps we just noticed that Alice's balance went negative), we can
issue the command ROLLBACK instead of COMMIT, and all our updates so far
will be canceled."
My understanding of all was that it includes sequences. Obviously, I'm
wrong... but how to do it right?
Cheers,
Frank
