From: | "Scott Marlowe" <smarlowe(at)qwest(dot)net> |
---|---|
To: | "Mike Nolan" <nolan(at)gw(dot)tssi(dot)com> |
Cc: | "pgsql general list" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: guaranteeing that a sequence never skips (fwd) |
Date: | 2004-10-03 18:11:53 |
Message-ID: | 1096827112.32732.23.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sun, 2004-10-03 at 11:48, Mike Nolan wrote:
> > On Sun, 2004-10-03 at 08:58, David Garamond wrote:
> > > Am I correct to assume that SERIAL does not guarantee that a sequence
> > > won't skip (e.g. one successful INSERT gets 32 and the next might be 34)?
> > >
> > > Sometimes a business requirement is that a serial sequence never skips,
> > > e.g. when generating invoice/ticket/formal letter numbers. Would an
> > > INSERT INTO t (id, ...) VALUES (SELECT MAX(col)+1 FROM t, ...) suffice,
> > > or must I install a trigger too to do additional checking?
> >
> > You will have to lock the whole table and your parallel performance will
> > be poor.
>
> Locking the table isn't sufficient to guarantee that a sequence value
> never skips. What if a transaction fails and has to be rolled back?
>
> I've written database systems that used pre-numbered checks, what's usually
> necessary is to postpone the check-numbering phase until the number of
> checks is finalized, so that there's not much chance of anything else
> causing a rollback.
> --
I didn't mean to use a sequence, sorry for being vague. I meant this:
lock table
select max(idfield)+1
insert new row
disconnect.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruno Wolff III | 2004-10-03 18:22:32 | Re: earthdistance is not giving correct results. |
Previous Message | Uwe C. Schroeder | 2004-10-03 18:01:46 | Re: guaranteeing that a sequence never skips |