From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | "Andrew G(dot) Hammond" <drew(at)xyzzy(dot)dhs(dot)org> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Bug? |
Date: | 2001-11-15 23:02:35 |
Message-ID: | 20011115145844.F10930-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> Is this correct behaviour? ACID compliant? The argument in it's favour it
> pretty obvious: if you never go backwards then you'll never get an accidental
> duplication as follows:
>
> t1 BEGIN; SELECT nextval('test_id_seq') # 1
> t2 SELECT nextval('test_id_seq') # 2
> t1 ROLLBACK # test_id_seq decremented
> t3 SELECT nextval('test_id_seq') # 2
>
> However wouldn't locking the sequence be more proper behaviour?
That's the intended behavior. Sequences aren't defined to give sequential
values, merely unique ones across their output set. The point is to
prevent two insert transactions from blocking on each other trying to get
the sequence value.
From | Date | Subject | |
---|---|---|---|
Next Message | Doug McNaught | 2001-11-15 23:17:28 | Re: Bug? |
Previous Message | Tom Lane | 2001-11-15 23:01:09 | Re: Delete performance |