LOCK

Name

LOCK  --  Explicit lock of a table inside a transaction トランザクション内部でのテーブルの明示的なロック。

Synopsis

LOCK [ TABLE ] table
LOCK [ TABLE ] table IN [ ROW | ACCESS ] { SHARE | EXCLUSIVE } MODE
LOCK [ TABLE ] table IN SHARE ROW EXCLUSIVE MODE
  

入力

table

The name of an existing table to lock.

ロックを行なう既存テーブルの名前。

ACCESS SHARE MODE

Note: This lock mode is acquired automatically over tables being queried. Postgres releases automatically acquired ACCESS SHARE locks after the statement is done.

このモードでは問い合わせが行なわれるテーブル全体のロックを自 動的に獲得します。Postgres は、そ の文が完了した後、自動的に獲得した ACCESS SHARE ロックを開放 します。

This is the least restrictive lock mode which conflicts only with ACCESS EXCLUSIVE mode. It is intended to protect a table being queried from concurrent ALTER TABLE, DROP TABLE and VACUUM statements over the same table.

これは、最も制限の弱いロックモードで、ACCESS EXCLUSIVE モード とのみコンフリクトします。あるテーブルに対する ALTER TABLEDROP TABLEVACUUM 文の同時実行からそのテーブルを保護 することが目的です。

ROW SHARE MODE

Note: Automatically acquired by any SELECT FOR UPDATE statement.

任意の SELECT FOR UPDATE 文によって自動的 に獲得されます。

Conflicts with EXCLUSIVE and ACCESS EXCLUSIVE lock modes.

EXCLUSIVE と ACCESS EXCLUSIVE ロックモードにコンフリクトします。

ROW EXCLUSIVE MODE

Note: Automatically acquired by any UPDATE, DELETE, INSERT statement.

任意の UPDATEDELETEINSERT 文によって自動的に獲得されます。

Conflicts with SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE and ACCESS EXCLUSIVE modes. Generally means that a transaction updated or inserted some tuples in a table.

SHARE、SHARE ROW EXCLUSIVE、EXCLUSIVE、ACCESS EXCLUSIVE モ ードにコンフリクトします。一般的には、あるトランザクション がテーブル内のいくつかのタプルの更新または挿入を行なったこ とを意味します。

SHARE MODE

Note: Automatically acquired by any CREATE INDEX statement.

CREATE INDEX 文によって自動的に獲得されます。

Conflicts with ROW EXCLUSIVE, SHARE ROW EXCLUSIVE, EXCLUSIVE and ACCESS EXCLUSIVE modes. This mode protects a table against concurrent updates.

ROW EXCLUSIVE、SHARE ROW EXCLUSIVE、EXCLUSIVE、ACCESS EXCLUSIVE モードにコンフリクトします。このモードは同時更新からテーブルを保 護します。

SHARE ROW EXCLUSIVE MODE

Conflicts with ROW EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE and ACCESS EXCLUSIVE modes. This mode is more restrictive than SHARE mode because of only one transaction at time can hold this lock.

ROW EXCLUSIVE、SHARE、SHARE ROW EXCLUSIVE、EXCLUSIVE、 ACCESS EXCLUSIVE モードにコンフリクトします。このモードはある 時刻に 1 つのトランザクションのみがこのロックを保有できるとい う理由で、SHARE モードよりも制限の強いものです。

EXCLUSIVE MODE

Conflicts with ROW SHARE, ROW EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE and ACCESS EXCLUSIVE modes. This mode is yet more restrictive than that of SHARE ROW EXCLUSIVE; it blocks all concurrent SELECT FOR UPDATE queries.

ROW SHARE、ROW EXCLUSIVE、SHARE、SHARE ROW EXCLUSIVE、 EXCLUSIVE、ACCESS EXCLUSIVE モードにコンフリクトします。この モードは SHARE ROW EXCLUSIVE よりもっと制限が強いものです。 このモードは全てのSELECT FOR UPDATE 問い合わせの同時実行をブ ロックします。

ACCESS EXCLUSIVE MODE

Note: Automatically acquired by ALTER TABLE, DROP TABLE, VACUUM statements.

ALTER TABLEDROP TABLE, VACUUM 文 によって自動的に獲得されます。

This is the most restrictive lock mode which conflicts with all other lock modes and protects a locked table from any concurrent operations.

これは最も制限の強いロックモードで、他の全てのロックモードとコ ンフリクトし、同時に起こる全ての操作からロックしたテーブルを保 護します。

Note: This lock mode is also acquired by an unqualified LOCK TABLE (i.e. the command without an explicit lock mode option).

このロックモードは条件を持たない(つまり、明示的なロックモー ドオプションが付いていない)LOCK TABLE に よっても獲得されます。

出力

LOCK TABLE

The lock was successfully applied.

ロックの適用に成功しました。

ERROR table: Table does not exist.

Message returned if table does not exist.

table が存在しな い場合に返されるメッセージ。

説明

Postgres always uses the least restrictive lock mode whenever possible. LOCK TABLE provided for cases when you might need more restrictive locking.

Postgres は可能である限り、常に最も制限 の弱いロックモードを使用します。より強い制限を持つロックを必要とす る場合のために LOCK TABLE が用意されています。

For example, an application runs a transaction at READ COMMITTED isolation level and needs to ensure the existance of data in a table for the duration of the transaction. To achieve this you could use SHARE lock mode over the table before querying. This will protect data from concurrent changes and provide any further read operations over the table with data in their actual current state, because SHARE lock mode conflicts with any ROW EXCLUSIVE one acquired by writers, and your LOCK TABLE table IN SHARE MODE statement will wait until any concurrent write operations commit or rollback.

例えば、アプリケーションが隔離レベル READ COMMITTED でトランザクシ ョンを実行し、そのトランザクションの間テーブルにデータが存在するこ とを確実にする必要がある場合を考えてみます。これを達成するために、 問い合わせ実行前にテーブル全体に SHARE ロックモードを使用することが できます。これは同時変更からデータを保護し、現在の実状態を維持した テーブル全体に対して読みとり操作を今後行なうことができます。SHARE ロックモードは、書き込み側によって獲得されるあらゆる ROW EXCLUSIVE とコンフリクトし、LOCK TABLE table IN SHARE MODE 文は同時書き込み操 作のコミットまたはロールバックが終るまで待つからです。

Note: To read data in their real current state when running a transaction at the SERIALIZABLE isolation level you have to execute a LOCK TABLE statement before execution any DML statement, when the transaction defines what concurrent changes will be visible to itself.

トランザクションが隔離レベル SERIALIZABLE で実行している時に、現 在の実状態のデータを読むためには、何らかの DML 文を実行するより前 に LOCK TABLE 文を実行する必要があります。このとき、そのトランザク ションはどんな同時変更を自身で認識できるかを定義します。

In addition to the requirements above, if a transaction is going to change data in a table then SHARE ROW EXCLUSIVE lock mode should be acquired to prevent deadlock conditions when two concurrent transactions attempt to lock the table in SHARE mode and then try to change data in this table, both (implicitly) acquiring ROW EXCLUSIVE lock mode that conflicts with concurrent SHARE lock.

上の要求事項に加え、トランザクションがテーブル内のデータを変更する 予定であるならば、SHARE ROW EXCLUSIVE ロックモードを獲得して、次の デッドロック状態を防止しなければなりません。2 つの同時トランザクシ ョンがテーブルを SHARE モードでテーブルをロックし、そしてテーブル 内のデータを変更しようとすると、両者は(暗黙的に)ROW EXCLUSIVE ロ ックモードを取得しようとしますが、このロックモードは同時 SHARE ロ ックとコンフリクトします。

To continue with the deadlock (when two transaction wait one another) issue raised above, you should follow two general rules to prevent deadlock conditions:

上で発生したデッドロック(2 つのトランザクションがお互いに待ってい る状態)に関する論点を続けると、デッドロック状態を防ぐために 2 つ の一般的なルールに従わなければなりません。

Note: Postgres does detect deadlocks and will rollback at least one waiting transaction to resolve the deadlock.

Postgres はデッドロックを検出し、少なく ても 1 つの待ち状態のトランザクションを、デッドロックを解消するた めにロールバックします。

注意

LOCK is a Postgres language extension.

LOCKPostgres の 拡張言語です。

Except for ACCESS SHARE/EXCLUSIVE lock modes, all other Postgres lock modes and the LOCK TABLE syntax are compatible with those present in Oracle.

ACCESS SHARE/EXCLUSIVE ロックモード以外の Postgres のロックモードと LOCK TABLE の構文は Oracle と互換性があります。

LOCK works only inside transactions.

LOCK はトランザクションの内側でのみ動作します。

使用法

Illustrate a SHARE lock on a primary key table when going to perform inserts into a foreign key table:

外部キーテーブルへの挿入を行なう際のプライマリキーテーブルへの SHARE ロックについて説明します。

BEGIN WORK;
LOCK TABLE films IN SHARE MODE;
SELECT id FROM films 
    WHERE name = 'Star Wars: Episode I - The Phantom Menace';

-- Do ROLLBACK if record was not returned
-- レコードが返されない場合は ROLLBACK を行なって下さい。
INSERT INTO films_user_comments VALUES 
    (_id_, 'GREAT! I was waiting for it for so long!');
COMMIT WORK;
   

Take a SHARE ROW EXCLUSIVE lock on a primary key table when going to perform a delete operation:

削除操作を行なう際にプライマリキーテーブルの SHARE ROW EXCLUSIVE ロックを取得します。

BEGIN WORK;
LOCK TABLE films IN SHARE ROW EXCLUSIVE MODE;
DELETE FROM films_user_comments WHERE id IN
    (SELECT id FROM films WHERE rating < 5);
DELETE FROM films WHERE rating < 5;
COMMIT WORK;
   

互換性

SQL92

There is no LOCK TABLE in SQL92, which instead uses SET TRANSACTION to specify concurrency level on transactions. We support that too; see SET for details.

SQL92 には LOCK TABLE は ありません。その代わりにトランザクションの同時性レベルを指定する SET TRANSACTION を使用します。Postgres はこれ もサポートしています。詳細については SET を参照し て下さい。