From: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
---|---|
To: | Jean-Christian Imbeault <jc(at)mega-bucks(dot)co(dot)jp> |
Cc: | techlist(at)voyager(dot)phys(dot)utk(dot)edu, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Duplicate key insert question |
Date: | 2003-07-02 01:36:36 |
Message-ID: | 20030702013636.GN27363@dcc.uchile.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Jul 02, 2003 at 10:25:54AM +0900, Jean-Christian Imbeault wrote:
> Reuben D. Budiardja wrote:
> >
> > No, onlu *one* of them will fail, but yes, the other will then generate error.
> > So it really is a trade off. Another way would be to lock the table, as other
> > has suggested. But then there is disadvantages to that also.
>
> Really? I just got a post form Alvaro Herrera saying;
>
> "The solution is not correct in that there _is_ a race condition."
>
> Maybe I misunderstood, but "not correct" doesn't sound good :)
Well, he is right. One will fail, the other will not. The race
condition is for the application. If you want to ignore it, you can do
that, but there _will_ be an ERROR thrown and the transaction will be
aborted. The other transaction _will_ insert the tuple, though, and it
won't be aborted.
Note that for the race condition to show there has to be a race, i.e.
two backends trying to insert the same primary key at the same time. If
one finishes half a second before the other, they will behave that way
you want, i.e. there will one tuple inserted and no error generated.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"No deja de ser humillante para una persona de ingenio saber
que no hay tonto que no le pueda enseñar algo." (Jean B. Say)
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2003-07-02 01:43:03 | Re: Duplicate key insert question |
Previous Message | Reuben D. Budiardja | 2003-07-02 01:32:59 | Re: Duplicate key insert question |