Thank you for the response. Can I clarify if I understood the essence correctly?
It turns out that despite the Read Committed isolation level, due to the presence of a unique index, which has an independent isolation mechanism, a transaction can "know" that a parallel transaction has performed an insert before it commits its changes. And it will wait for the completion or rollback of the parallel transaction, after which it will be clear whether it can insert the row or if it needs to perform an alternative operation (update or do nothing)? This is very interesting! I would like to see this description in the documentation.
Why does the documentation say <Again, this is only the case in Read Committed mode>? Is the behavior different in other isolation levels? What is it like? The documentation does not say anything about the behavior of INSERT in the Repeatable Read and Serializable isolation levels.
Or does it mean that contrary to Read
Committed Isolation Level, uncommitted changes from a parallel transaction
can affect the execution of an INSERT command?
This. Because you are keying off of an unique index that has independent isolation mechanics. Upon attempting to insert a row that will violate the unique constraint enforced by the index the system must wait to see whether the earlier transaction commits. If it doesn't, the insert proceeds. If it does, the conflict clause is evaluated - updating the now committed row (or just doing nothing if that option is specified.)
David J.
