Transaction isolation and constraints

Поиск
Список
Период
Сортировка
От cliff@krumvieda.com
Тема Transaction isolation and constraints
Дата
Msg-id 200712041348.lB4DmBpT032722@phumos.tgtaft.emc.com
обсуждение исходный текст
Ответы Re: Transaction isolation and constraints  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
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 isolation levels, Read Committed and Serializable).  But
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:

  o Will the "first" INSERT wait to see if the "second" aborts (as is
    done with UPDATE, DELETE, et al.)?

  o Or will it immediately abort?

  o Or will it continue until immediately before commit, then abort?

It's not clear when the constraint check is run (or what version of
the table it sees).

Note this point isn't specific to INSERTs, another example would be
two concurrent transactions that UPDATE completely different rows and
in so doing violate a UNIQUE constraint.

Thanks.

                --Cliff Krumvieda

В списке pgsql-general по дате отправления:

Предыдущее
От: "Josh Harrison"
Дата:
Сообщение: Re: initdb - encoding question
Следующее
От: "Wim Chalmet"
Дата:
Сообщение: Vacuum output redirect