From: | Doug McNaught <doug(at)wireboard(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:17:28 |
Message-ID: | m3n11nbp4n.fsf@belphigor.mcnaught.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Andrew G. Hammond" <drew(at)xyzzy(dot)dhs(dot)org> writes:
> 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?
As I understand it, this is one case where efficiency wins out--if you
locked the sequence some apps could end up with a lot of lock
contention. So we don't lock, don't roll back and work fine except
that there can be gaps in a SERIAL column.
I don't think sequences are in the SQL standard so we're not really
violating anything. ;)
-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863
From | Date | Subject | |
---|---|---|---|
Next Message | Francisco Reyes | 2001-11-15 23:33:17 | Re: pgsql and large tables |
Previous Message | Stephan Szabo | 2001-11-15 23:02:35 | Re: Bug? |