The view <structname>pg_locks</structname> provides access to information about the locks held by active processes within the database server. See <xref linkend="mvcc"/> for more discussion of locking. pg_locksビューはデータベースサーバ内でアクティブなプロセスによって保持されたロックに関する情報へのアクセスを提供します。 ロックに関するより詳細な説明は第13章を参照してください。

<structname>pg_locks</structname> contains one row per active lockable object, requested lock mode, and relevant process. Thus, the same lockable object might appear many times, if multiple processes are holding or waiting for locks on it. However, an object that currently has no locks on it will not appear at all. pg_locksにはロック対象となる進行中のオブジェクト、要求されたロックモード、および関連するプロセス毎に1つの行を持ちます。 ですから、もし複数のプロセスが同じロック対象オブジェクトに対してロックを保持していたりロックを待機している場合には、同じロック対象オブジェクトが何度も出現することがあります。 しかし現在ロックされていないオブジェクトはまったく現れません。

There are several distinct types of lockable objects: whole relations (e.g., tables), individual pages of relations, individual tuples of relations, transaction IDs (both virtual and permanent IDs), and general database objects (identified by class OID and object OID, in the same way as in <link linkend="catalog-pg-description"><structname>pg_description</structname></link> or <link linkend="catalog-pg-depend"><structname>pg_depend</structname></link>). Also, the right to extend a relation is represented as a separate lockable object, as is the right to update <structname>pg_database</structname>.<structfield>datfrozenxid</structfield>. Also, <quote>advisory</quote> locks can be taken on numbers that have user-defined meanings. ロック対象オブジェクトには異なる型がいくつか存在します。 リレーション全体（例：テーブル）、リレーションの個別のページ、リレーションの個別のタプル、トランザクションID（仮想と永続の両方のID）、一般的なデータベースオブジェクト（これはpg_descriptionやpg_dependと同様にクラスOIDとオブジェクトOIDで識別されます）。 さらに、リレーションを拡張する権利は、pg_database.datfrozenxidを更新する権利と同様に、別のロック対象オブジェクトとして表現されます。 また「勧告的」ロックはユーザ定義の意味を持つ複数から形成されるかもしれません。

<structfield>granted</structfield> is true in a row representing a lock held by the indicated process. False indicates that this process is currently waiting to acquire this lock, which implies that at least one other process is holding or waiting for a conflicting lock mode on the same lockable object. The waiting process will sleep until the other lock is released (or a deadlock situation is detected). A single process can be waiting to acquire at most one lock at a time. 指定されたプロセスにより保持されているロックを表す行内ではgrantedはtrueです。 falseの場合は、このロックを獲得するため現在プロセスが待機中であることを示しています。 つまり、同じロック対象のオブジェクトに対して何らかの他のプロセスが競合するロックを保持、もしくは待機していることを意味します。 待機中のプロセスはその別のプロセスがロックを解放するまで活動を控えます。 （もしくはデッドロック状態が検出されることになります）。 単一プロセスでは一度に多くても1つのロックを獲得するために待機します。

Throughout running a transaction, a server process holds an exclusive lock on the transaction's virtual transaction ID. If a permanent ID is assigned to the transaction (which normally happens only if the transaction changes the state of the database), it also holds an exclusive lock on the transaction's permanent transaction ID until it ends. When a process finds it necessary to wait specifically for another transaction to end, it does so by attempting to acquire share lock on the other transaction's ID (either virtual or permanent ID depending on the situation). That will succeed only when the other transaction terminates and releases its locks. トランザクションの実行中は常に、サーバプロセスはその仮想トランザクションID上に排他的ロックをかけます。 もしある永続IDがトランザクションに割り当てられる（普通はトランザクションがデータベースの状態を変化させるときのみに発生します）と、トランザクションは終了するまで永続トランザクションIDに対して排他ロックを保持します。 あるトランザクションが他のトランザクションを特定して終了まで待機しなければならないと判断した場合、他とみなしたトランザクションのIDに対し共有ロックを獲得するように試み、目的を達します。 （仮想IDであるか永続IDであるかは、その状況によります）。 これは、他とみなしたトランザクションが完了し、そしてロックを解放した場合のみ成功します。

Although tuples are a lockable type of object, information about row-level locks is stored on disk, not in memory, and therefore row-level locks normally do not appear in this view. If a process is waiting for a row-level lock, it will usually appear in the view as waiting for the permanent transaction ID of the current holder of that row lock. タプルはロック対象のオブジェクト種類ですが、行レベルロックについての情報はメモリではなく、ディスクに保存されます。 よって行レベルロックは通常、このビューには現れません。 もしプロセスが行レベルロックの待ち状態である場合は、その行ロックを保持している永続トランザクションIDを待つ状態で、そのトランザクションはビューに現れます。

A speculative insertion lock consists of a transaction ID and a speculative insertion token. The speculative insertion token is displayed in the <structfield>objid</structfield> column. 投機的挿入ロックは、トランザクションIDと投機的な挿入トークンから構成されます。 投機的な挿入トークンはobjid列に表示されます。

Advisory locks can be acquired on keys consisting of either a single <type>bigint</type> value or two integer values. A <type>bigint</type> key is displayed with its high-order half in the <structfield>classid</structfield> column, its low-order half in the <structfield>objid</structfield> column, and <structfield>objsubid</structfield> equal to 1. The original <type>bigint</type> value can be reassembled with the expression <literal>(classid::bigint &lt;&lt; 32) | objid::bigint</literal>. Integer keys are displayed with the first key in the <structfield>classid</structfield> column, the second key in the <structfield>objid</structfield> column, and <structfield>objsubid</structfield> equal to 2. The actual meaning of the keys is up to the user. Advisory locks are local to each database, so the <structfield>database</structfield> column is meaningful for an advisory lock. 勧告的ロックは、単一のbigint値、または、2つの整数値をキーとして獲得できます。 bigintの場合は、その上位半分がclassid列内に表示され、残りの下位半分はobjid列内に表示されます。 また、objsubidは1です。 元のbigint値を(classid::bigint << 32) | objid::bigintという式で再構成できます。 整数値キーでは、最初のキーがclassid列に、2番目のキーがobjid列に表示され、objsubidは2です。 キーの実際の意味はユーザに任されています。 勧告的ロックはデータベースに対して局所的ですので、勧告的ロックではdatabase列が意味を持ちます。

Apply transaction locks are used in parallel mode to apply the transaction in logical replication. The remote transaction ID is displayed in the <structfield>transactionid</structfield> column. The <structfield>objsubid</structfield> displays the lock subtype which is 0 for the lock used to synchronize the set of changes, and 1 for the lock used to wait for the transaction to finish to ensure commit order. 適用トランザクションロックは、論理レプリケーションでトランザクションを適用するために並列モードで使用されます。 リモートトランザクションIDはtransactionid列に表示されます。 objsubidは、ロックのサブタイプを表示します。 これは、変更のセットを同期するために使用されるロックの場合は0で、トランザクションを終了してコミット順序を保証するために使用されるロックの場合は1です。

<structname>pg_locks</structname> provides a global view of all locks in the database cluster, not only those relevant to the current database. Although its <structfield>relation</structfield> column can be joined against <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield> to identify locked relations, this will only work correctly for relations in the current database (those for which the <structfield>database</structfield> column is either the current database's OID or zero). pg_locksは現行のデータベースに関連するロックのみならず、データベースクラスタ内のすべてのロックに関する全体的なビューを提供します。 relation列はロックされたリレーションを識別するためにpg_class.oidと結合できますが、これは現行のデータベース内のリレーション（database列が現行のデータベースのOIDまたはゼロとなっているもの）に対してのみ正常に動作します。

The <structfield>pid</structfield> column can be joined to the <structfield>pid</structfield> column of the <link linkend="monitoring-pg-stat-activity-view"> <structname>pg_stat_activity</structname></link> view to get more information on the session holding or awaiting each lock, for example それぞれのロックを保持もしくは待機しているセッションのさらなる情報を入手するためpg_stat_activityビューのpid列とpid列を結合できます。 例えば、このような感じです。

SELECT * FROM pg_locks pl LEFT JOIN pg_stat_activity psa
    ON pl.pid = psa.pid;

Also, if you are using prepared transactions, the <structfield>virtualtransaction</structfield> column can be joined to the <structfield>transaction</structfield> column of the <link linkend="view-pg-prepared-xacts"><structname>pg_prepared_xacts</structname></link> view to get more information on prepared transactions that hold locks. (A prepared transaction can never be waiting for a lock, but it continues to hold the locks it acquired while running.) For example: また、プリペアドトランザクションを使用している場合には、ロックを保持しているプリペアドトランザクションに関してより多くの情報を得るため、virtualtransaction列は、pg_prepared_xactsビューのtransaction列と結合できます。 （プリペアドトランザクションはロックを待つことはありませんが、実行時に獲得したロックを保持し続けます。） 例えば、このような感じです。

SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
    ON pl.virtualtransaction = '-1/' || ppx.transaction;

While it is possible to obtain information about which processes block which other processes by joining <structname>pg_locks</structname> against itself, this is very difficult to get right in detail. Such a query would have to encode knowledge about which lock modes conflict with which others. Worse, the <structname>pg_locks</structname> view does not expose information about which processes are ahead of which others in lock wait queues, nor information about which processes are parallel workers running on behalf of which other client sessions. It is better to use the <function>pg_blocking_pids()</function> function (see <xref linkend="functions-info-session-table"/>) to identify which process(es) a waiting process is blocked behind. pg_locksビューとそれ自身の結合によって、どのプロセスが他のどのプロセスをブロックしているかの情報を入手することが可能ですが、同時に詳細な正しい情報を得ることは非常に困難です。 このようなクエリはどのロックモードが他のものと衝突しているかについての知見を書き出すべきです。 さらに悪いことに、pg_locksビューは、ロック待ちキューにてどのプロセスが他のどのプロセスに先行しているかの情報を提供しない、またはどのプロセスが他のクライアントセッションのために動作している並列ワーカープロセスかの情報を提供しません。 待機しているプロセスが、どのプロセスにブロックされているかを識別するためにより良い方法は、pg_blocking_pids()関数（表 9.69を参照してください）を使用することです。

The <structname>pg_locks</structname> view displays data from both the regular lock manager and the predicate lock manager, which are separate systems; in addition, the regular lock manager subdivides its locks into regular and <firstterm>fast-path</firstterm> locks. This data is not guaranteed to be entirely consistent. When the view is queried, data on fast-path locks (with <structfield>fastpath</structfield> = <literal>true</literal>) is gathered from each backend one at a time, without freezing the state of the entire lock manager, so it is possible for locks to be taken or released while information is gathered. Note, however, that these locks are known not to conflict with any other lock currently in place. After all backends have been queried for fast-path locks, the remainder of the regular lock manager is locked as a unit, and a consistent snapshot of all remaining locks is collected as an atomic action. After unlocking the regular lock manager, the predicate lock manager is similarly locked and all predicate locks are collected as an atomic action. Thus, with the exception of fast-path locks, each lock manager will deliver a consistent set of results, but as we do not lock both lock managers simultaneously, it is possible for locks to be taken or released after we interrogate the regular lock manager and before we interrogate the predicate lock manager. pg_locksビューは、異なるシステムにおける、通常のロックマネージャと述語ロックマネージャの両方からのデータを表示します。 さらに通常のロックマネージャではロックを通常ロックと近道ロックに細分化します。 このデータが完全に一貫性があることは保証されません。 ビューが問い合わせられると、近道ロック（fastpath = trueが真）は、ロックマネージャ全体の状態を凍結することなく、各バックエンドからひとつひとつ収集されます。 このため情報収集期間中にロックが獲得されたり解放されたりされる可能性があります。 しかし、これらのロックはその時点で存在する他のロックと競合することがないことが分かっていることに注意してください。 近道ロックについてすべてのバックエンドを問い合わせた後、通常のロックマネージャの残りは１つの単位としてロックされ、残りすべてのロックの一貫性があるスナップショットを原子的な処理で収集します。 ロックマネージャのロックを解除した後、述語ロックマネージャは同様にロックされ、すべての述語ロックを原子的な処理で収集します。 このように、近道ロックという例外がありますが、各ロックマネージャは一貫性をもった結果セットを生成します。 しかし、両方のロックマネージャを同時にロックしませんので、通常のロックマネージャを問い合わせた後と述語ロックマネージャを問い合わせる前の間にロックが獲得されたり解放されたりされる可能性があります。

Locking the regular and/or predicate lock manager could have some impact on database performance if this view is very frequently accessed. The locks are held only for the minimum amount of time necessary to obtain data from the lock managers, but this does not completely eliminate the possibility of a performance impact. このビューが頻繁にアクセスされている場合は、通常もしくは述語ロックマネージャをロックするとデータベースのパフォーマンスに影響があります。 ロックマネージャからデータを取得するために、ロックは必要最低限の時間だけ保持されますが、パフォーマンスに影響がある可能性が全くないわけではありません。