Re: Serial not so unique?
От | Joe Conway |
---|---|
Тема | Re: Serial not so unique? |
Дата | |
Msg-id | 018c01c12837$fec6ac70$0705a8c0@jecw2k1 обсуждение исходный текст |
Ответ на | Serial not so unique? (Stephen Robert Norris <srn@commsecure.com.au>) |
Ответы |
Re: Serial not so unique?
|
Список | pgsql-general |
> > > Sometimes (about 20%, it seems) with several of the data sets, we > > > get an error trying to insert rows into the table with the serial in it. > > > On investigation, it seems that the serial number has got to 101, then > > > set itself back to 4, causing nextval to return 5, and there are already > > > entries from 1-101. > > > > > > Now, we use the serial as the primary key, and we never explicitly set it. > > > > > > Has anyone seen anything like this? I can work around it by generating > > > a serial number within the application, but that's not ideal. > > > > Odd problem. What do you get if you run: > > select * from name_of_this_troublesome_sequence; > > particularly for increment_by, max_value, min_value, and is_cycled? > > > > -- Joe > > 1, 2^31 -1, 1, f > > Stephen Nothing stands out there. You might try to drop and recreate the sequence if you haven't already. Or, a longshot, but . . . you might check the table definition to be sure it's using the sequence that you think it is. -- Joe
В списке pgsql-general по дате отправления: