| From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
|---|---|
| To: | josh(at)agliodbs(dot)com |
| Cc: | Jaime Casanova <systemguards(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Subject: | Re: MERGE vs REPLACE |
| Date: | 2005-11-16 00:12:25 |
| Message-ID: | 200511160012.jAG0CPO10639@candle.pha.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Josh Berkus wrote:
> Jaime,
>
> > why? seems that REPLACE only work if there are at least one row
> > matching...
>
> Scenario:
>
> session1: REPLACE .... 1
> session2: REPLACE ..... 1
> session1: check to see that "1" exists .... no
> session2: check to see that "1" exists .... no
> session1: INSERT 1
> session2: INSERT 1 .... ERROR
>
> Get the picture? The only way to avoid a race condition is to be able to
> do "predicate locking", that is to lock the table against any data write
> matching that predicate.
Isn't the standard practice to do the INSERT, and if that fails, do
the UPDATE? In fact, if someone is already doing a INSERT inside a
transaction, it will wait for the transaction to complete so you can
then do the UPDATE, or complete the INSERT if the transaction aborted.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2005-11-16 00:16:21 | Re: MERGE vs REPLACE |
| Previous Message | Trent Shipley | 2005-11-15 23:27:01 | Re: [ADMIN] Major Problem, need help! Can't run our website! |