|
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 |
