[EMAIL PROTECTED] wrote:
> Hi, Tom:
>
> >Whichever one manages to get to the index page first will go through.
> >The second one will block waiting to see if the first one commits,
> >and will error out if so --- or proceed, if it aborts.
>
> I see, this makes sense. What if the two transactions
Hi, Tom:
>Whichever one manages to get to the index page first will go through.
>The second one will block waiting to see if the first one commits,
>and will error out if so --- or proceed, if it aborts.
I see, this makes sense. What if the two transactions insert rows
that don't violate the con
[EMAIL PROTECTED] writes:
> suppose a table has a UNIQUE constraint on a column, and two
> concurrent transactions attempt to INSERT a row with the same value
> for that column:
Whichever one manages to get to the index page first will go through.
The second one will block waiting to see if the fi
Hi:
I'd like to know how PostgreSQL's transaction isolation mechanisms
interact with (e.g., UNIQUE) constraints. Section 12.2 of the manual
mentions that UPDATE, DELETE, SELECT FOR UPDATE, and SELECT FOR SHARE
commands may block when a concurrent transaction updates a target row
(for both isolati
