Subject: Re: Atomar SQL Statement
From: Scott Marlowe <smarlowe@g2switchworks.com>
To: Stephan Szabo <sszabo@megazone.bigpanda.com>
Cc: Michael Glaesemann <grzm@seespotcode.net>, "Weber,
	Johann (ISS Kassel)" <jweber@iss.net>, pgsql-sql@postgresql.org
In-Reply-To: <20060707105847.J77811@megazone.bigpanda.com>
References: <B8ADDBDA8696F546BDAC69B469D7F0512E06F3@kasmaiexcp01.iss.net>
	<279E27B5-183F-4520-BC43-A726A50646EF@seespotcode.net>
	<20060707105847.J77811@megazone.bigpanda.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1152298181.22269.30.camel@state.g2switchworks.com>
Mime-Version: 1.0
Date: Fri, 07 Jul 2006 13:49:41 -0500

On Fri, 2006-07-07 at 13:07, Stephan Szabo wrote:
> On Fri, 7 Jul 2006, Michael Glaesemann wrote:
> 
> >
> > On Jul 7, 2006, at 7:55 , Weber, Johann (ISS Kassel) wrote:
> >
> > > My concern: in a multi threaded environment, can a second thread
> > > interrupt this statement and eventually insert the same email
> > > address in
> > > the table with a different id? Or is this statement atomar?
> >
> > You're safe. Take a look at the FAQ entries on SERIAL:
> >
> > http://www.postgresql.org/docs/faqs.FAQ.html#item4.11.2
> 
> I don't think he is, because I don't think the issue is the SERIAL
> behavior, but instead the NOT EXISTS behavior.  Won't the NOT EXISTS in
> read committed potentially be true for both concurrent sessions if the
> second happens before the first commits, which then would mean that both
> sessions will go on to attempt the insert (with their own respective ids
> from the serial)? Without a unique constraint on email I think he can end
> up with the same email address with two different ids.

Yep, this is a possible race condition, if memory serves, and this is
the reason for unique indexes.  That way, should another transaction
manage to sneak in between the two parts of this query, the unique index
will still keep your data coherent.