| 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: | Whole Thread | Raw Message | 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? |