Tom Lane-2 wrote
> In your example, you've already committed the other insertion of "2",
> right? So the serializable transaction *must* fail to insert "2".
Sure.
Tom Lane-2 wrote
> The current coding chooses to give you a "duplicate key" error on
> the grounds that that's more helpful than a generic "serialization
> failure" error.
But it seems counterintuitive. PostgreSQL reports that there is conflicting
row, so I look... and don't see it! Surprising, IMHO.
But why is it more helpful?
It seems that in this situation, if I need, for example, to insert or update
this row (if it exists), my transaction is doomed anyway. So if I got
"serialization failure", I wouldn't even try to 'ROLLBACK TO SAVEPOINT', as
it's pointless (right?). With "duplicate key" error, I may decide that
committed row actually exists and try to update it in vain.
Tom Lane-2 wrote
> The debate around bug #12330 is about whether that
> is the best choice of error code ... but one way or the other, you're
> going to get an error. On the other hand, the SELECT step isn't going
> to show you the "2", because it's in the future so far as the
> transaction's snapshot is concerned.
Ok, I understand the principle behind it. Thanks a lot!
-----
WBR, Yaroslav Schekin.
--
View this message in context: http://postgresql.nabble.com/How-do-concurrent-inserts-work-tp5832157p5832174.html
Sent from the PostgreSQL - novice mailing list archive at Nabble.com.