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