Re: Duplicate key insert question

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)

In response to

Responses

Browse pgsql-general by date

  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