I encountered the same problem. The machine it happenned on _may_ have had
a power outage before I noticed the problem. (I know it had one a while back
when on the workbench, but I can't remember if that was before or after I'd
setup the tables)
BTW, this was a debian box, running the 7.1release-4 package.
On Sat, Aug 18, 2001 at 03:55:28PM +1000, Stephen Robert Norris wrote:
> We have a table here with a serial value in it.
>
> We have sets of test data that we run through a processor that changes
> a fairly large set of tables in deterministic ways.
>
> 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.
>
> Is this another RTFM question?
>
> Stephen
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
--
Michael Samuel
Tech Guy
michael@hyperlink.net.au
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Hyperlink, a division of The Swish Group Ltd
ACN 085 545 973
Level 6, 257 Collins St, Melbourne, VIC 3004
Phone 1300 368 638 Fax +61 3 9211 5406
http://www.hyperlink.net.au
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
