Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> In Mikko's both examples, Transaction 1 has to see a tuple
> which didn't exist at the beginning of the transaction
> while checking duplicate error.
I'm not sure about that. What if the "tuple that didn't exist" is
an updated version of a row that did exist earlier --- that is, the
conflicting operation is an update not an insert? Does your answer
change depending on whether the update changed the row's key value?
In the most straightforward implementation of your suggestion, I believe
that a concurrent update (on a non-key column) would result in the
system randomly delivering either "duplicate key" or "serialization
error" depending on whether the index processing happened to look at
the older or newer other tuple first. That definitely does not strike
me as an improvement over the current behavior.
In any case, I still think that this'd be trading a useful error message
(ie, one that tells you what is wrong) for a uselessly non-specific one.
regards, tom lane