Re: failed insert into serial-type row

hi,

i'm working with an postgresql-installation on Solaris ("PostgreSQL
7.4.7 on sparc-sun-solaris2.9, compiled by GCC 2.95.3") and I have the
following problem:

I'm using tables like this:
--------------------------------
CREATE TABLE session.preferences
(
id serial NOT NULL,
name varchar(50),
value varchar(255),
CONSTRAINT session_preferences_pkey PRIMARY KEY (id)
)
WITHOUT OIDS;
ALTER TABLE session.preferences OWNER TO web;
--------------------------------

and sometimes if i'm adding new rows to the table with statements like
this:
insert into (name,value) ('xy','xy');
the database only returns an 'duplicate key on primary key', which
should be prevented by the serial-datatype, or? how could it be, that
two rows become the same id??
if i execute the insert-statement again it works.

the created serial-sequence looks like this:
--------------------------------
CREATE SEQUENCE session.preferences_id_seq
INCREMENT 1
MINVALUE 1
MAXVALUE 9223372036854775807
START 2487
CACHE 1;
ALTER TABLE session.preferences_id_seq OWNER TO web;
--------------------------------

what can I do against the duplicate-key problem? is it a configuration,
sql or operating-system specific problem?

with kind regards
stefan

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> and sometimes if i'm adding new rows to the table with statements like
> this:
> insert into (name,value) ('xy','xy');

Show us the actual SQL, not something "like" it. The above is not valid.

> CREATE SEQUENCE session.preferences_id_seq
> START 2487

You haven't shown us how this sequence is attached to the table. Presumably
with:

ALTER TABLE preferences ALTER id SET DEFAULT nextval('preferences_id_seq');

That START qualifier is a red flag. If the sequence was not created when the table
was, one explanation is that there are existing values in the table that are higher
than the current sequence. Running
SELECT max(id) FROM preferences
and
SELECT * FROM preferences_id_seq;
should show that. The other possibility is that someone is inserting into the table
and specifying a value for the id field manually.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200506180957
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iD8DBQFCtCoLvJuQZxSWSsgRAkiVAKDG6eVWdCdqzbnQnqIOHyoZ/ijzOACfcgh+
9P9fUQbyJUXebzHvOf4F3Z8=
=QKrK
-----END PGP SIGNATURE-----

On Mon, Jun 13, 2005 at 21:58:37 +0200,
"Hortschitz, Stefan" <Stefan(dot)Hortschitz(at)lfrz(dot)at> wrote:
>
> CREATE TABLE session.preferences
> (
> id serial NOT NULL,
> name varchar(50),
> value varchar(255),
> CONSTRAINT session_preferences_pkey PRIMARY KEY (id)
> )
> WITHOUT OIDS;
> ALTER TABLE session.preferences OWNER TO web;
> --------------------------------
>
> and sometimes if i'm adding new rows to the table with statements like
> this:
> insert into (name,value) ('xy','xy');
> the database only returns an 'duplicate key on primary key', which
> should be prevented by the serial-datatype, or? how could it be, that
> two rows become the same id??
> if i execute the insert-statement again it works.
>
> the created serial-sequence looks like this:
> --------------------------------
> CREATE SEQUENCE session.preferences_id_seq
> INCREMENT 1
> MINVALUE 1
> MAXVALUE 9223372036854775807
> START 2487
> CACHE 1;
> ALTER TABLE session.preferences_id_seq OWNER TO web;
> --------------------------------
>
> what can I do against the duplicate-key problem? is it a configuration,
> sql or operating-system specific problem?

Most likely you recreated the table and reloaded it at some point without
restoring the sequence value.

What you want to do now is set the sequence to the highest value of id
in the table. Something like:
SELECT setval('preferences_id_seq',(SELECT max(id) FROM session.preferences);