Thread: 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@turnstep.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.Hortschitz@lfrz.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);