Re: 13.2.1. Read Committed Isolation Level

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.

вт, 16 июл. 2024 г. в 20:38, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>:

> On Tue, Jul 16, 2024 at 7:06 AM PG Doc comments form <
> noreply(at)postgresql(dot)org> wrote:
>
>> 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.
>
>