Yaroslav wrote
>
> Serge Fonville wrote
>> When I tested the same queries I get the same behaviour.
>> When both are SERIALIZABLE, the second insert just waits
>>
>> When one is default (unspecified) and the other is SERIALIZABLE, the
>> behaviour is the same as you describe.
> Just re-tested, and no, it doesn't wait and behaves exactly as I
> described.
> My PostgreSQL version is: "PostgreSQL 9.3.4, compiled by Visual C++ build
> 1600, 32-bit", if it's relevant.
Thinking aloud here but...
There is nothing that says you must be able to see the value with which you
are conflicting. The argument boils down to when the error occurs:
mid-transaction or at commit. Mid-transaction is definitely more useful...
Savepoints and serializable transactions, iirc, are problematic in joint
usage because of the usual flow of control and this behavior where you are
trying to use data in-transaction that you cannot see but that the system
knows you are conflicted with. The system largely expects the error to
stick and for you to likely retry the whole thing and not just rollback to a
savepoint.
David J.
--
View this message in context: http://postgresql.nabble.com/How-do-concurrent-inserts-work-tp5832157p5832167.html
Sent from the PostgreSQL - novice mailing list archive at Nabble.com.
