Tom Lane wrote: > What would you have it do differently? Accept the insert and then give > some random error message at the commit? I'm sorry, but I don't see > a problem here. > regards, tom lane
Thanks Tom I would like to see error message 'ERROR: Can't serialize access due to concurrent updates' during the transaction (after insert or commit). The difference is that by receiving that message I know that there is nothing wrong in the sql statements, in the database or in the program logic. After that I could retry. If I get any other error message I cannot tell should I retry or not. In my case I have a table where I have timestamped values. For each timestamp there can be only one value. If a get a new value with the same timestamp I need to overwrite the old one. This must happend in one transaction. By first deleteng and then inserting a value in one transaction I can be sure that I don't delete anything without inserting and it also works fine when there isn't anything to delete. But now I get "random" error messages. I could check for 'ERROR: Cannot insert a duplicate key into unique index ?', but for more complicated cases I would have to check for many other error messages too. And because there aren't really any numeric error codes that would be impossible. But all those errors really are because of serialization problems. So shouldn't I be receiving a error stating that? regards Mikko ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly