Вся предоставленная на этом сервере информация собрана нами из разных источников. Если Вам кажется, что публикация каких-то документов нарушает чьи-либо авторские права, сообщите нам об этом.
Serializable provides the highest transaction isolation.
When a transaction is on the serializable level,
a query sees only data
committed before the transaction began and never see either dirty data
or concurrent transaction changes committed during transaction
execution. So, this level emulates serial transaction execution,
as if transactions would be executed one after another, serially,
rather than concurrently.
If a row returned by query while executing a
UPDATE
(or DELETE or SELECT FOR UPDATE)
statement is being updated by
a concurrent uncommitted transaction then the second transaction
that tries to update this row will wait for the other transaction to
commit or rollback. In the case of rollback, the waiting transaction
can proceed to change the row. In the case of a concurrent
transaction commit, a serializable transaction will be rolled back
with the message
ERROR: Can't serialize access due to concurrent update
because a serializable transaction cannot modify rows changed by
other transactions after the serializable transaction began.
Note: Note that results of execution of SELECT
or INSERT (with a query)
will not be affected by concurrent transactions.
