Re: On duplicate ignore

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Florian Weimer <fweimer(at)bfk(dot)de>
Cc: gnanam(at)zoniac(dot)com, Atul Goel <Atul(dot)Goel(at)iggroup(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: On duplicate ignore
Date: 2012-01-19 16:50:11
Message-ID: CAOR=d=3k-xyjRHyF6-0a-v+fXi3JGq7b8i-M1izD8Y=KKFu3CQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Jan 19, 2012 at 9:49 AM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:
> On Thu, Jan 19, 2012 at 7:54 AM, Florian Weimer <fweimer(at)bfk(dot)de> wrote:
>> * Gnanakumar:
>>
>>>> Just create a unique index on EMAIL column and handle error if it comes
>>>
>>> Thanks for your suggestion.  Of course, I do understand that this could be
>>> enforced/imposed at the database-level at any time.  But I'm trying to find
>>> out whether this could be solved at the application layer itself.  Any
>>> thoughts/ideas?
>>
>> If you use serializable transactions in PostgreSQL 9.1, you can
>> implement such constraints in the application without additional
>> locking.  However, with concurrent writes and without an index, the rate
>> of detected serialization violations and resulting transactions aborts
>> will be high.
>
> No, you sadly can't.  PostgreSQL doesn't yet support proper predicate
> locking to allow the application to be sure that the OP's original
> statement, and ones like it, don't have a race condition.  A unique
> index is the only way to be sure.

Wait, did 9.1 implement proper predicate locking to allow this? If so
I apologize for being out of the loop on the new versions.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Florian Weimer 2012-01-19 16:53:14 Re: On duplicate ignore
Previous Message Scott Marlowe 2012-01-19 16:49:15 Re: On duplicate ignore