Re: Insert behavior in transaction - Mailing list pgsql-general

From Andres
Subject Re: Insert behavior in transaction
Date
Msg-id 20050620020850.14725.qmail@gawab.com
Whole thread Raw
In response to Re: Insert behavior in transaction  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
But, does it have solution ??

You are right, the second insert imply a unique-key violation,
but what to do in that cases?

Thanks for your help and attention!


Tom Lane writes:

> "Andres" <andres1981@gawab.com> writes:
>> I did this simple test and it fails too.
>
>> BEGIN (first transaction)
>> INSERT INTO mytable VALUES(1);
>
>> On other client
>> BEGIN (second transaction)
>> INSERT INTO mytable VALUES(0);
>> INSERT INTO mytable VALUES(1);
>
>> and it freezes waiting for the first o commit or rollback
>
> Not too surprising if the second insert would imply a unique-key
> violation.  It has to wait to see if the first insertion of "1"
> is going to commit or not.
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match


pgsql-general by date:

Previous
From: John DeSoi
Date:
Subject: Re: user/groups query ?
Next
From: Michael Fuhr
Date:
Subject: Re: plpgsql constraint checked data fails to restore