Re: creating "job numbers"

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "postgresql" <pgsql(at)symcom(dot)com>
Cc: "Jan Wieck" <JanWieck(at)Yahoo(dot)com>, "PgSQL-SQL" <pgsql-sql(at)postgresql(dot)org>
Subject: Re: creating "job numbers"
Date: 2001-03-23 15:56:23
Message-ID: 18064.985362983@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

"postgresql" <pgsql(at)symcom(dot)com> writes:
> Using the serial data type... I don't understand when the backend
> would skip a number.

The value returned by a nextval() call will not be returned again by
other nextval() calls, even if the surrounding transaction is later
rolled back. Agreed, this isn't in line with full transactional
semantics, but it was deemed the more useful thing to do precisely
because of that. If you want the other behavior you can build it
yourself, whereas there's no way to build the actual behavior of
sequence objects in plain SQL.

The reason why this is more useful is that with this behavior,
acquirers of serial numbers don't need to wait for each other. A
no-skipped-numbers implementation requires each would-be acquirer to
block waiting to see if previous acquirers commit or not. You get no
concurrency at all if you build your system like that.

regards, tom lane

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Tom Lane 2001-03-23 16:29:56 Re: Btree index on varchar
Previous Message postgresql 2001-03-23 15:21:49 RE: creating "job numbers"