PostgreSQL では、テーブル レベルのロックを使用してこれをテストし、競合するトランザクションが同時に実行されることを確認できます。設定:
CREATE TABLE place (id serial primary key, state_code integer, type text);
INSERT INTO place (state_code, type) VALUES (5, 'town'), (6, 'town');
次に、セッション T0 で:
BEGIN; LOCK TABLE place;
2 つの新しいセッションで、T1 と T2 のコマンドを発行します。
T0 号に戻ります。
ROLLBACK;
テーブルレベルのロックを解放し、T1 と T2 が競合できるようにします。
分離した場合(READ COMMITTED
デフォルト) は両方とも転置されますが、現実の世界では、これはトランザクションの正確な順序に依存し、信頼することはできません。
REPEATABLE READ
(PostgreSQL 9.0 では分離と呼ばれる)では、それらは両方とも転置されますが、単一ステートメントのトランザクションでは両方が本質的に同等であるためSERIALIZABLE
、 と同じ注意事項があります。READ COMMITTED
スナップショットは、最初のステートメントが実行されたときに取得されますBEGIN
。.
SERIALIZABLE
単独で、GUC または を介して設定するdefault_transaction_isolation
とBEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE
、一方のトランザクションはシリアライゼーションの失敗でコミットに失敗し、もう一方は成功し、どのトランザクションが勝ったかに応じて、すべての行がstate_code
5 になるか、すべての行が6 になります。state_code
SQL Server もトランザクションの 1 つを中止する場合、適切なシリアル化を行っています。
SQL Server は適切なシリアル化に従いました (厳密なシリアル化が要求された場合の現在のバージョンの PostgreSQL と同様)。一方、テスト済みのバージョンの PostgreSQL はREAD COMMITTED
分離 (シリアル化が想定されていない) または 9.1 より前のSERIALIZABLE
分離 (これはこの異常を検出できませんでした)、厳密なトランザクションのシリアライゼーションのセマンティクスには従いませんでした。
default_transaction_isolation
が以外に設定されている場合、これは PostgreSQL 9.2 で発生する可能性があり、SERIALIZABLE
PostgreSQL 9.1 より前の標準でした。
SQL Server が使用しているようSET TRANSACTION ISOLATION LEVEL
です。PostgreSQL では、default_transaction_isolation
GUCまたはSET TRANSACTION ISOLATION LEVEL
. SQL Server で既定のトランザクション分離レベルをグローバルに設定できるかどうかは不明です。