> -----Original Message-----
> From: Alvaro Herrera [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 01, 2003 6:37 PM
> To: Jean-Christian Imbeault
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [GENERAL] Duplicate key insert question
>
>
> 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.
I assume that PostgreSQL would simply time out both transactions if it
happened in a deadly-embrace pair?
I searched the PG docs, but could not find a clear answer.
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
