X-Original-To: pgsql-sql-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id A65559FB1DB for ; Fri, 7 Jul 2006 16:42:23 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 66692-01 for ; Fri, 7 Jul 2006 16:42:15 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey- Received: from hu-out-0102.google.com (hu-out-0102.google.com [72.14.214.206]) by postgresql.org (Postfix) with ESMTP id 182BB9FA192 for ; Fri, 7 Jul 2006 16:42:14 -0300 (ADT) Received: by hu-out-0102.google.com with SMTP id 23so1642943huc for ; Fri, 07 Jul 2006 12:42:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=qZSXR+M56GKcLKLC4mUSrUIDbddw+GKxSAxej6ZPaCuMPjxMIDLxyyGmm1JHUDI4e/JXQwMNljWhmyOZfZMz9+5JW0P2heBziy+wb/sg19bNEBt7sSVdLD0paDYBKHTZ0+GG9LveFF0jS+55BjOzUCdS3MLmCRLeavqv4qbPwkU= Received: by 10.78.122.11 with SMTP id u11mr858296huc; Fri, 07 Jul 2006 12:42:10 -0700 (PDT) Received: by 10.78.29.2 with HTTP; Fri, 7 Jul 2006 12:42:10 -0700 (PDT) Message-ID: Date: Fri, 7 Jul 2006 14:42:10 -0500 From: "Aaron Bono" To: pgsql-sql@postgresql.org Subject: Fwd: Atomar SQL Statement In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4796_16724268.1152301330890" References: <279E27B5-183F-4520-BC43-A726A50646EF@seespotcode.net> <20060707105847.J77811@megazone.bigpanda.com> <1152298181.22269.30.camel@state.g2switchworks.com> X-Google-Sender-Auth: b99ad47e5800aa97 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200607/115 X-Sequence-Number: 25689 ------=_Part_4796_16724268.1152301330890 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/7/06, Scott Marlowe wrote: > 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. I deal with these issues by first placing a unique constraint on the email field (as was suggested above) and then synchronizing the code that does the check and insert. I have also looked for instances where a unique constraint error is thrown and had the system give the user a meaningful error or responded appropriately. -Aaron ------=_Part_4796_16724268.1152301330890 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/7/06, Scott Marlowe < smarlowe@g2switchworks.com> wrote:
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.

I deal with these issues by first placing a unique constraint on the email field (as was suggested above) and then synchronizing the code that does the check and insert.  I have also looked for instances where a unique constraint error is thrown and had the system give the user a meaningful error or responded appropriately.

-Aaron
------=_Part_4796_16724268.1152301330890--