mark@mark.mielke.cc wrote:
> On Thu, Nov 17, 2005 at 10:15:30AM -0500, Stephen Frost wrote:
> > REPLACE/INSERT ON DUPLICATE UPDATE appears to essentially be a
> > transaction which is supposed to not fail but instead do locking to
> > ensure that it doesn't fail. This requires predicate locking to be
> > efficient because you want to tell the concurrent transaction "if you
> > have the same key as me, just wait a second and you can do an update
> > 'cause I'm going to create the key if it doesn't exist before I'm done".
>
> Is the requirement for predicate locking, over and above a unique
> constraint on an index that involves the record key, to deal with
> the scenario of two inserts executing at the same time, both before
> commit?

No. If you have a primary key you can easily prevent duplicates. You
need a table lock or predicate locking to prevent duplicates if you do
not have a primary key.

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster