[EMAIL PROTECTED] 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
