Обсуждение: 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
On Tue, Jun 14, 2005 at 07:28:22AM +0200, Hortschitz, Stefan wrote:
>
> 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??
One possibility is that the table contains IDs that are higher than
the sequence value, so you occasionally get duplicates when you use
the sequence. What are the results of the following queries?
SELECT max(id) FROM session.preferences;
SELECT * FROM session.preferences_id_seq;
If max(id) is higher than the sequence's last_value, then you can
adjust the sequence with setval() or ALTER SEQUENCE. Then you
should to figure out how that happened so you can prevent it from
happening again.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/