PostgreSQL 9.1.5文書 | ||||
---|---|---|---|---|
前のページ | 巻戻し | 第 13章同時実行制御 | 早送り | 次のページ |
PostgreSQLは、テーブル内のデータに対する同時アクセスを制御するために様々な種類のロックモードを備えています。 これらのモードは、MVCCでは必要な動作を得られない場合、アプリケーション制御のロックに使用することができます。 また、ほとんどのPostgreSQLコマンドでは、参照されるテーブルがそのコマンドの実行中に別の方法で削除もしくは変更されていないことを確実にするために、適切なモードのロックを自動的に獲得します。 (例えば、TRUNCATEコマンドは、同じテーブルに対する他の操作とは同時に実行することは危険です。 そのため、そのテーブルへの排他ロックを強制的に獲得します。)
現在のデータベースサーバで重要なロックの一覧を確認するには、pg_locksシステムビューを使用してください。 ロック管理サブシステムの状況監視についての詳細は第27章を参照してください。
以下のリストに、PostgreSQLで自動的に使用される、使用可能なロックモードとその文脈を示します。 また、LOCKコマンドを使用して、こうしたロックを明示的に獲得することもできます。 これらのロックモードは、たとえその名前に"row(行)"という言葉が付いていても、全てテーブルレベルのロックであることに注意してください。 ロックモードの名前は歴史的なものです。 これらの名前は、各ロックモードの代表的な使用方法をある程度表しています。 しかし、意味的には全て同じです。 ロックモード間における唯一の実質的な差異は、どのモードがどのモードと競合するかというロックモードの組み合わせです(表13-2を参照してください)。 2つのトランザクションで、競合するモードのロックを同時に同一テーブル上に保持することはできません (しかし、トランザクションは自分自身とは決して競合しません。 例えば、ACCESS EXCLUSIVEロックを獲得し、その後同じテーブルにACCESS SHAREロックを獲得できる可能性があります)。 競合しないロックモードは、多くのトランザクションで同時に保持することが可能です。 特に、ロックモードには、自己競合するもの(例えば、ACCESS EXCLUSIVEは同時に複数のトランザクションで保持することは不可能)と、自己競合しないもの(例えば、ACCESS SHAREは複数のトランザクションで保持可能)があることに注意してください。
テーブルレベルロックモード
ACCESS EXCLUSIVEロックモードとのみ競合します。
SELECTコマンドにより、参照されるテーブルに対してこのモードのロックが獲得されます。 通常、テーブルの読み取りのみで変更を行わない問い合わせであれば全て、このロックモードを獲得します。
EXCLUSIVEおよびACCESS EXCLUSIVEロックモードと競合します。
SELECT FOR UPDATEおよびSELECT FOR SHAREコマンドは、(参照はされているが、FOR UPDATE/FOR SHAREとして選択はされていない他のテーブルに対するACCESS SHAREロックに加えて)対象となるテーブル上にこのモードのロックを獲得します。
SHARE、SHARE ROW EXCLUSIVE、EXCLUSIVE、およびACCESS EXCLUSIVEロックモードと競合します。
UPDATE、DELETE、およびINSERTコマンドは、(参照される他の全てのテーブルに対するACCESS SHAREロックに加えて)対象となるテーブル上にこのモードのロックを獲得します。 通常、このロックモードは、テーブルのデータを変更する問い合わせにより獲得されます。
SHARE UPDATE EXCLUSIVE、SHARE、SHARE ROW EXCLUSIVE、EXCLUSIVE、およびACCESS EXCLUSIVEロックモードと競合します。 このモードにより、同時実行されるスキーマの変更およびVACUUMコマンドの実行から、テーブルを保護します。
(FULLなしの)VACUUMコマンド、ANALYZEコマンド、CREATE INDEX CONCURRENTLY、および、ALTER TABLEのいくつかの形式によって獲得されます。
ROW EXCLUSIVE、SHARE UPDATE EXCLUSIVE、SHARE ROW EXCLUSIVE、EXCLUSIVE、およびACCESS EXCLUSIVEロックモードと競合します。 このモードは、同時実行されるデータ変更からテーブルを保護します。
(CONCURRENTLYなしの)CREATE INDEXによって獲得されます。
ROW EXCLUSIVE、SHARE UPDATE EXCLUSIVE、 SHARE、SHARE ROW EXCLUSIVE、EXCLUSIVE、およびACCESS EXCLUSIVEロックモードと競合します。 このモードは、1つのセッションだけが一度にそれを保持することができるよう、自己排他的に同時のデータ変更からテーブルを保護します。
このロックモードを自動的に獲得するPostgreSQLコマンドはありません。
ROW SHARE、ROW EXCLUSIVE、 SHARE UPDATE EXCLUSIVE、SHARE、 SHARE ROW EXCLUSIVE、EXCLUSIVE、およびACCESS EXCLUSIVEロックモードと競合します。 このモードは、同時実行されるACCESS SHAREのみを許可します。 つまり、このロックモードを保持するトランザクションと並行して実行できる処理は、テーブルの読み取りだけです。
ユーザテーブルに対してこのロックモードを自動的に獲得するPostgreSQLコマンドはありません。
全てのモードのロック(ACCESS SHARE、ROW SHARE、ROW EXCLUSIVE、SHARE UPDATE EXCLUSIVE、SHARE、SHARE ROW EXCLUSIVE、EXCLUSIVE、および ACCESS EXCLUSIVE)と競合します。 このモードにより、その保持者以外にテーブルにアクセスするトランザクションがないことが保証されます。
ALTER TABLE、DROP TABLE、TRUNCATE、REINDEX、CLUSTER、VACUUM FULLコマンドによって獲得されます。 また、明示的にモードを指定しなければ、これがLOCK TABLE文を使用する際のデフォルトのロックモードです。
ティップ: ACCESS EXCLUSIVEロックのみが、SELECT(FOR UPDATE/SHAREなし)文をブロックします。
通常ロックは獲得した後、トランザクションの終わりまで保持されます。 しかし、ロックがセーブポイントの確立後に獲得された場合、セーブポイントがロールバックされると、ロックは即座に解放されます。 これは、ROLLBACKがセーブポイント以降に行われたすべてのコマンドの効果を取消すという原則と整合性が取れています。 PL/pgSQL例外ブロック内で獲得されたロックに対しても同様です。 PL/pgSQL例外ブロック内で獲得されたロックに対しても道央です。 そのブロックからエラーで抜けた後、獲得されたロックは解放されます。
テーブルレベルロックに加えて、排他ロックまたは共有ロックを行うことができる、行レベルロックがあります。 特定の行に対する行レベルの排他ロックは、行が更新または削除される時に自動的に獲得されます。 トランザクションがコミットまたはロールバックされるまで、単にテーブルレベルロックのように、このロックは保持されます。 行レベルロックは、データの問い合わせには影響を与えません。 行レベルロックは、同じ行に対する書き込みだけををブロックします。
実際に行を変更せずに行に対して行レベルロックを獲得するには、該当する行をSELECT FOR UPDATEで選択してください。 いったん行レベルロックが獲得されると、競合を心配しないで、そのトランザクション内では何回でも行の変更が可能であるということを覚えておいてください。
ある行に対する行レベルの共有ロックを獲得するには、SELECT FOR SHAREを使用してその行を選択してください。 共有ロックは、他のトランザクションによる同じ共有ロックの獲得を阻害しません。 しかし、他のトランザクションが共有ロックを保持している行に対して、更新、削除、排他ロックの獲得を行うことができるトランザクションはありません。 これらを試すと、共有ロックが解放されるまでブロックされます。
PostgreSQLでは、メモリ上に変更された行の情報を記憶しないため、同時にロックできる行数の上限はありません。 しかし、行をロックする際に、ディスクに書き込む作業が発生するかもしれません。 例えばSELECT FOR UPDATEは、選択された行をロックしたものと印を付けるために変更を行いますので、ディスクにその結果を書き込むことになります。
テーブルと行ロックに加え、ページレベルの共有/排他ロックがあり、これらは共有バッファプールにあるテーブルページへの読み書きのアクセスを管理するために使用されます。 これらのロックは、行が取得された後や更新された後に即座に解除されます。 アプリケーション開発者は通常ページレベルロックを考慮する必要はありませんが、ロックについて全てを説明したかったためここで取り上げました。
明示的なロックの使用は、デッドロックの原因となる可能性があります。 デッドロックとは、2つ(もしくはそれ以上)のトランザクションにおいて、それぞれが、他方のトランザクションが必要とするロックを所持してしまうことです。 例えば、トランザクション1がテーブルAに排他ロックを獲得していて、次にテーブルBに排他ロックを獲得しようとする際に、トランザクション2が既にテーブルBに排他ロックを獲得済みであって、今からテーブルAに排他ロックを獲得しようと試みる場合、どちらのトランザクションも処理を進められません。 PostgreSQLでは、自動的にデッドロック状況を検知し、関係するトランザクションの一方をアボートすることにより、この状況を解決し、もう一方のトランザクションの処理を完了させます (どちらのトランザクションをアボートするかを正確に予期するのは難しく、これに依存すべきではありません)。
デッドロックは行レベルロックの結果として発生する可能性があります (したがって、明示的なロック処理を使用していなくても発生する可能性があります)。 2つの同時実行トランザクションがあるテーブルを変更する状況を考えてみます。 1つ目のトランザクションは以下を実行します。
UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 11111;
これは、指定した口座番号の行に対し行レベルロックを獲得します。 次に2番目のトランザクションが以下を実行します。
UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 22222; UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 11111;
1つ目のUPDATE文は指定された行に対する行レベルロックの獲得に成功し、この行の更新に成功します。 しかし、2つ目のUPDATE文は、更新対象の行がロックされていることを検知し、ロックを獲得したトランザクションが完了するまで待機します。 トランザクション2は、ここで、続きを実行する前にトランザクション1が完了するのを待機しています。 さて、トランザクション1がここで以下を実行します。
UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 22222;
トランザクション1は指定した行の行レベルロックを獲得しようとしますが、これは不可能です。 トランザクション2がそのロックを既に獲得しているからです。 そのため、トランザクション2が完了するのを待機することになります。 こうして、トランザクション1はトランザクション2でブロックされ、トランザクション2はトランザクション1でブロックされる、つまり、デッドロック状態です。 PostgreSQLはデッドロック状態を検知し、片方のトランザクションを中断させます。
デッドロックを防ぐ最も良い方法は、データベースを使用する全てのアプリケーションが、整合性のある順序で複数のオブジェクトに対するロックを獲得することです。 前に示したデッドロックの例で、もし両方のトランザクションで同じ順序で行を更新していたらデッドロックは起こりません。 また、トランザクション内のオブジェクトに対して獲得した最初のロックが、そのオブジェクトが必要とする最も制限的なモードであることを確実に保証すべきです。 このことが事前に検証できない場合、デッドロックによりアボートするトランザクションを再試行すれば、デッドロックをデータベースを稼働させながらでも処理することができます。
デッドロック状況が検出されなければ、テーブルレベルロックもしくは行レベルロックを要求するトランザクションは、競合するロックが解放されるまで、無期限に待機します。 したがって、アプリケーションで長時間(例えば、ユーザの入力待ち)トランザクションを開いたまま保持しておくのは、推奨されません。
PostgreSQLは、アプリケーション独自の意味を持つロックを生成する手法を提供します。 これは、その使用に関してシステムによる制限がないこと、つまり、正しい使用に関してはアプリケーションが責任を持つことから勧告的ロックと呼ばれます。 勧告的ロックは、MVCC方式に合わせづらいロック計画で有用に使用することができます。 例えば、一般的な勧告的ロックの使用方法は、よく"フラットファイル"データ管理システムと呼ばれる、悲観的ロックの戦略をエミュレートすることです。 同様の目的で、テーブル内にフラグを格納することもできますが、勧告的ロックの方が高速で、テーブルの肥大化を防ぐことができ、またセッション終了時にはサーバにより自動的に除去されます。
PostgreSQLには、2つの異なるタイプの勧告的ロックがあります。 セッションレベルとトランザクションレベルがあります。セッションレベルで一旦獲得すると、勧告的ロックは明示的に解放されるか、セッションが終了するまで保持されます。 標準的なロック要求とは異なり、セッションレベルでの勧告的ロック要求はトランザクションという意味には従いません。 ロックがトランザクション期間中に獲得され、そのトランザクションを後でロールバックしたとしても、ロールバック後も保持されます。 そして、呼び出し元のトランザクションが後で失敗したとしてもアンロックは有効です。 所有するプロセスの中でロックを複数回獲得することもできます。 この場合、個々の完了したロック要求に対して、ロックを実際に解放する前に対応するアンロック要求が存在しなければなりません。 一方トランザクションレベルのロックは、より通常ロック要求に似たような動作します。 それらは、トランザクションの終わりに自動的に解放され、明示的にアンロックすることはできません。 この動作は、セッションレベルで勧告的ロックを短期間で使用する動作よりも、より便利な場合が多くあります。 セッションレベルとトランザクションレベルで、同じ勧告的ロックの識別子を使ったロック要求は、期待通り互いにブロックするでしょう。 セッションが与えられた勧告的ロックを既に保持していれば、他のセッションがロックを待っていても、追加の要求は常に成功するでしょう。 これについては、既存のロックおよび新しい要求がセッションレベル、トランザクションレベルのどちらであっても、そのようになります。
すべてのPostgreSQLのロックと同様、 任意のセッションで現在保持されている勧告的ロックはすべて、pg_locksシステムビューで列挙されています。
勧告的ロックと通常ロックはどちらも共有メモリプールに格納され、その容量はmax_locks_per_transactionとmax_connections設定変数により決定されます。 このメモリを浪費しないように注意が必要です。 さもないと、サーバはロック獲得をまったく許可することができなくなります。 これは、サーバで許可できる勧告的ロック数に上限があることを意味します。 サーバの設定によりますが、通常、1万から10万程度になります。
特に明示的な順序付けとLIMIT句を持つ問い合わせでは、勧告的ロックモードを使用する幾つかの場合において、SQL式が評価される順序を考慮し獲得されたロックを制御することに気を配らなければなりません。 以下に例を示します。
SELECT pg_advisory_lock(id) FROM foo WHERE id = 12345; -- 問題なし SELECT pg_advisory_lock(id) FROM foo WHERE id > 12345 LIMIT 100; -- 危険! SELECT pg_advisory_lock(q.id) FROM ( SELECT id FROM foo WHERE id > 12345 LIMIT 100 ) q; -- 問題なし
上の例では、ロック獲得関数が実行される前にLIMIT が適用されることを保障できないため、2番目の形式は危険です。 これにより、アプリケーションが想定していないなんからのロックが生成される可能性があります。 そのため、(セッションが終了するまで)解放に失敗することになります。 アプリケーションから見ると、こうしたロックはただの飾りですが、pg_locksからは参照され続けます。
勧告的ロックを扱うための関数については、表9-62で説明します。