Поведение уровней изоляции PostgreSQL

Question

Я читаю раздел 13.2 Руководства PostgreSQL , но найденные там текстовые описания недостаточно ясны и не содержат примеров.

Например, следующие два абзаца неясныкому изучается PostgreSQL:

INSERT с предложением ON CONFLICT DO UPDATE ведет себя аналогично.В режиме Read Committed каждая строка, предложенная для вставки, будет либо вставлена, либо обновлена.Если нет несвязанных ошибок, один из этих двух результатов гарантирован.Если конфликт возникает в другой транзакции, эффекты которой еще не видны для INSERT, предложение UPDATE повлияет на эту строку, даже если, возможно, ни одна из версий этой строки традиционно не видна команде. "

и

Режим многократного чтения обеспечивает строгую гарантию того, что каждая транзакция видит полностью стабильное представление базы данных, однако это представление не всегда будет соответствовать последовательному (по одному) выполнению.одновременных транзакций одного уровня. Например, даже транзакция только для чтения на этом уровне может видеть контрольную запись, обновленную, чтобы показать, что пакет завершен, но не увидеть одну из подробных записей, которая логически является частью пакета, потому что онапрочтите более раннюю версию контрольной записи.

Может ли кто-нибудь привести примеры, поясняющие, что содержится в этих двух абзацах?

Кто-нибудь знает, где можно найти формальное описание поведенияPostgreSQL изоляция levels?Я ищу это, потому что это сложная тема, которая, как мне кажется, формальное описание поможет прояснить, как это работает, и, следовательно, поможет избежать ошибок параллелизма между транзакциями.

ОБНОВЛЕНИЕ : еще одно сомнениеУ меня есть вопрос: как обрабатывается сериализуемая транзакция с точки зрения того, как механизм базы данных решает зафиксировать или прервать ее, когда он может работать одновременно с другими транзакциями на других уровнях изоляции?Решает ли база данных результат сериализуемой транзакции, как если бы другие транзакции также выполнялись с сериализуемой изоляцией?

Спасибо

ОБНОВЛЕНИЕ 2 : Пока что лучшийв отношении деталей реализации уровней изоляции можно найти PostgreSQL Wiki Serializable Page .

Answer 1

Относительно вопроса в ОБНОВЛЕНИЕ

Решает ли база данных результат сериализуемой транзакции, как если бы другие транзакции также выполнялись с сериализуемой изоляцией? "

ответом является НЕТ.

Сериализуемость проверяется только между параллельными транзакциями на сериализуемом уровне изоляции . Например, для двух транзакций T1 и T2, чередующихся так:

T1: begin
T1: set transaction isolation level read committed;
T1: update addresses set street = 'Sun street' where id = 1
T2: begin
T2: set transaction isolation level serializable;
T2: select street from addresses where id = 1
T2: update addresses set street = 'Sea street' where id = 2
T1: select street from addresses where id = 2
T1: commit
T2: commit

и T1, и T2 будут фиксироваться, однако, если T1 установлен на сериализуемую изоляцию, T2 прервется.

Answer 2

• READ COMMITTED: каждый оператор SQL делает новый снимок базы данных, поэтому каждый оператор всегда будет видеть изменения, сделанные параллельными транзакциями, в то же время, как только онисовершено.Ошибки сериализации быть не могут.

• REPEATABLE READ: первый оператор в транзакции делает снимок базы данных, которая сохраняется для всей транзакции, поэтому всеоператоры видят то же состояние базы данных.Ошибки сериализации могут возникнуть, если вы попытаетесь изменить строку, которая была изменена параллельной транзакцией после того, как был сделан ваш снимок.Этот уровень изоляции не дороже, чем READ COMMITTED.

• SERIALIZABLE: любая транзакция, которая может привести к результату, который не согласуется с некоторым последовательным выполнениемпорядок транзакций будет прерван с ошибкой сериализации.Там могут быть ложные срабатывания.Этот уровень изоляции является более дорогим, чем другие.

Ответы на конкретные вопросы:

• INSERT ... ON CONFLICT в прочитанной подтвержденной изоляции:

  Если транзакция 1 вставила строку, но еще не зафиксирована, транзакция 2, выполняющая INSERT ... ON CONFLICT, будет ожидать, пока транзакция 1 не зафиксировала или не откатилась, а затем обновится или вставится соответствующим образом.Нарушения ограничений не может быть.

• Пакетные задания и REPEATABLE READ:

  Этот параграф темный;игнорируй это.Он пытается проиллюстрировать, что два одновременных повторяющихся преобразования чтения могут привести к результату, который не согласуется ни с одним последовательным выполнением.

  Лучшим примером могут быть две одновременные транзакции, которые одновременно читают одни и те же данные и выполняют обновления на их основепрочитанные результаты.Каждая из этих транзакций не может видеть модификации другой.

  Более подробные примеры можно найти в вики PostgreSQL под "serializable".

• Вопрос об обновлении:

  Этот вопрос мне не совсем понятен.

  Сериализуемые транзакции принимают специальные блокировки "SI", которые отслеживают доступ на чтение и запись и выдерживают фиксацию.Они не блокируют другие сеансы, но используются для определения, может ли быть конфликт.Сериализуемый уровень изоляции работает правильно, только если все параллельные транзакции используют сериализуемый уровень изоляции.