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
