On Tue, 16 Jul 2002, Nic Gibson wrote: > On Tue, Jul 16, 2002 at 03:56:23PM +0100, Alex McLintock wrote: > > At 10:47 16/07/02, Roger Burton West wrote: > > >On or about Tue, Jul 16, 2002 at 10:43:17AM +0100, Peter Haworth typed: > > > > > >>Surely you shouldn't rely on sequences being contiguous, anyway? Who cares > > >>if your test eats up some values; their only purpose should be to ensure > > >>uniqueness. > > > > > >Contiguity becomes important when you're doing things like generating > > >invoice numbers. > > > > > > 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. > > MSSQL works in the expected manner. It's about the only one I can think of. >
Informix does as well, and whilst I am no big database theory expert I wouldn't have thought it was a very difficult problem to solve, only really requiring exclusive access to the metadata wherein the serial column's value is stored (if it is held in metadata rather than solely in the table it lives in), as I understand it the Informix serial column data is stored in the indexes (the serial column having an implicit index on it) and as a database thread requires exclusive and transactional access to the index whilst doing an insert this gives rise to the expected behaviour. The problems arise when you start getting into an update-any replication situation and you have used the serial column as the primary key ... /J\
