On Wed, Jul 17, 2002 at 11:33:10AM +0100, Peter Haworth wrote: > On Tue, 16 Jul 2002 15:59:20 +0100, Nic Gibson wrote: > > On Tue, Jul 16, 2002 at 03:56:23PM +0100, Alex McLintock wrote: > > > For the record I hit this sort of problem doing some perl web stuff with > > > Oracle. It seemed that because Oracle was multiprocessor each oracle > > > process would grab for itself the next 20 ids. if you stopped and > > > started the server there would be a gap of 19 between consecutive > > > requests.... > > > > This happens with postgres too. Because each client gets a new backend > > process, the sequence can only be guaranteed to increment safely. It can't > > be guranteed to increase by only one. > > Postgres sequences dont get rolled back with transactions, either. Since > this is a good thing, the same is probably true of all those other databases > I haven't used. Without these protections, a transaction would need > exclusive access to the sequence, which forces serialisation. If you want > that, you can implement it yourself easily enough.
/me thinks it's a very good thing. It's true for Oracle AFAIR. > > > MSSQL works in the expected manner. It's about the only one I can > > think of. > > "Expected" doesn't necessarily mean "correct". That's why I said 'expected' :) nic -- if the real jesus christ was to stand up today he'd be gunned down cold by the cia
