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@xxxxxxxxx> 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 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
