From: | "Joe Conway" <joseph(dot)conway(at)home(dot)com> |
---|---|
To: | <srn(at)commsecure(dot)com(dot)au> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Serial not so unique? |
Date: | 2001-08-18 22:49:10 |
Message-ID: | 018c01c12837$fec6ac70$0705a8c0@jecw2k1 |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2001-08-18 23:04:10 | Re: COPY and triggers |
Previous Message | Stephen Robert Norris | 2001-08-18 22:35:38 | Re: Serial not so unique? |