以下のリストに、使用可能なロックモードとそれらがPostgreSQLで自動的に使用される文脈を示します。 また、LOCKコマンドを使用して、こうしたロックを明示的に獲得することもできます。 これらのロックモードは、たとえその名前に「row（行）」という言葉が付いていても、全てテーブルレベルのロックであることに注意してください。 ロックモードの名前は歴史的なものです。 これらの名前は、各ロックモードの代表的な使用方法をある程度表しています。 しかし、意味的には全て同じです。 ロックモード間における唯一の実質的な差異は、どのモードがどのモードと競合するかというロックモードの組み合わせです(表 13.2を参照してください)。 2つのトランザクションで、競合するモードのロックを同時に同一テーブル上に保持することはできません （しかし、トランザクションは自分自身とは決して競合しません。 例えば、ACCESS EXCLUSIVEロックを獲得し、その後同じテーブルにACCESS SHAREロックを獲得できる可能性があります）。 競合しないロックモードは、多くのトランザクションで同時に保持することが可能です。 特に、ロックモードには、自己競合するもの（例えば、ACCESS EXCLUSIVEは同時に複数のトランザクションで保持することは不可能）と、自己競合しないもの（例えば、ACCESS SHAREは複数のトランザクションで保持可能）があることに注意してください。

通常ロックは獲得した後、トランザクションの終わりまで保持されます。 しかし、ロックがセーブポイントの確立後に獲得された場合、セーブポイントがロールバックされると、ロックは即座に解放されます。 これは、ROLLBACKがセーブポイント以降に行われたすべてのコマンドの効果を取消すという原則と整合性が取れています。 PL/pgSQL例外ブロック内で獲得されたロックに対しても同様です。 そのブロックからエラーで抜けた後、獲得されたロックは解放されます。

テーブルレベルロックに加えて、行レベルロックがあります。PostgreSQLが自動的に使う文脈付きで以下に行レベルロックの一覧があります。 行レベルロックの競合の完全な表については表 13.3を参照してください。 トランザクションは異なる副トランザクション内であっても、同じ行に対して競合するロックを保持できることに注意してください。 しかし、それ以外では、二つのトランザクションは同じ行に対して競合するロックを決して保持できません。 行レベルロックは、データの問い合わせには影響を与えません。 行レベルロックは、同じ行に対する書き込みとロックだけをブロックします。 テーブルレベルロックと同じように、行レベルロックはトランザクションの終わり、または、セーブポイントへのロールバックで解放されます。

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には、セッションレベルとトランザクションレベルという２つの勧告的ロックの獲得方法があります。 セッションレベルで獲得すると、勧告的ロックは明示的に解放されるか、セッションが終了するまで保持されます。 標準のロック要求と異なり、セッションレベル勧告的ロックはトランザクションという意味には従いません。 ロックがトランザクション期間中に獲得され、そのトランザクションを後でロールバックしたとしても、ロールバック後も保持されます。 そして、呼び出し元のトランザクションが後で失敗したとしてもロック解除は有効です。 所有するプロセスの中で、同一のセッションレベルのロックを複数回獲得することもできます。 この場合、個々のロック要求に対して、ロックを実際に解放する前に対応するロック解除要求がなければなりません。 一方トランザクションレベルのロックはより通常のロックに似たように動作します。 それらは、処理の終わりに自動的に解放されますので、明示的なロック解放操作はありません。 短期間の勧告的ロックを利用する場合は、セッションレベルの動作よりもこの動作の方が便利なことが多くあります。 同じ勧告的ロック識別子に対するセッションレベルのロックとトランザクションレベルのロック要求は、想像通り互いをブロックします。 セッションがすでに指定された勧告的ロックを保持している場合、他のセッションがそのロックを待機していたとしても、追加の要求は常に成功します。 これは保持されているロックと新しい要求がセッションレベルかトランザクションレベルかどうかに関わらず、この文は当てはまります。

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.27.10で説明します。