Skip site navigation (1) Skip section navigation (2)

Re: BUG #4307: INSERT fails with primary key contraint

From: Oskars Ozols <oskars(dot)ozols(at)gmail(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4307: INSERT fails with primary key contraint
Date: 2008-07-17 08:10:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
I use NHibernate and Npgsql 0.7.1 database driver for data 
access layer. From your comments it looks like these components are 
responsible for INSERT statement creation (mostly NHibernate).

I think you can close this bug and I will search for solutions in 
NHibernate community.

Gregory Stark wrote:
> "Oskars Ozols" <oskars(dot)ozols(at)gmail(dot)com> writes:
>>   id bigint NOT NULL DEFAULT nextval(('public.event_log_id_seq'::text)::regclass), 
>> 2008-07-15 12:32:03 EEST STATEMENT:  INSERT INTO public.event_log
>> (date_time, ip_address, action_type, severity, parameters, web_address,
>> server, user_id, id) VALUES ('2008-07-15 12:28:50.000000',
>> '', 'WebServices.SomeService:LogError', 70000, 'error text',
>> '', '4', 75, 156112)
> There's something strange here. Your SQL statement includes the id as a
> literal constant 156112. This isn't the normal way to write this query. This
> is defeating the point of the DEFAULT you see in the table definition.
> Postgres guarantees that the nextval() function will only return each value
> once. But it's not clear from this log how your application is generating the
> 156112 value which it is explicitly putting in the query. If it's getting it
> by calling nextval() then it's somehow using it twice.
> It's also possible someone has written code to pick primary key values by
> calling "select max(id)+1". That is guaranteed to have race conditions like
> this.
> The safest thing to do is to just leave out the id column from your INSERT
> statement. Just let the DEFAULT expression generate a value for you. Then you
> can use curval('event_log_id_seq') to find out what value it generated.

Oskars Ozols

In response to

pgsql-bugs by date

Next:From: ITAGAKI TakahiroDate: 2008-07-17 10:09:16
Subject: Re: MAX関数に関する報告
Previous:From: Dave PageDate: 2008-07-17 07:41:08
Subject: Re: BUG #4312: Installation fails

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group