LOCK [ TABLE ] table LOCK [ TABLE ] table IN [ ROW | ACCESS ] { SHARE | EXCLUSIVE } MODE LOCK [ TABLE ] table IN SHARE ROW EXCLUSIVE MODE
The name of an existing table to lock.
ロックを行なう既存テーブルの名前。
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 TABLE、DROP TABLE、 VACUUM 文の同時実行からそのテーブルを保護 することが目的です。
Note: Automatically acquired by any SELECT FOR UPDATE statement.
任意の SELECT FOR UPDATE 文によって自動的 に獲得されます。
Conflicts with EXCLUSIVE and ACCESS EXCLUSIVE lock modes.
EXCLUSIVE と ACCESS EXCLUSIVE ロックモードにコンフリクトします。
Note: Automatically acquired by any UPDATE, DELETE, INSERT statement.
任意の UPDATE、DELETE、 INSERT 文によって自動的に獲得されます。
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 モ ードにコンフリクトします。一般的には、あるトランザクション がテーブル内のいくつかのタプルの更新または挿入を行なったこ とを意味します。
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 モードにコンフリクトします。このモードは同時更新からテーブルを保 護します。
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 モードよりも制限の強いものです。
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 問い合わせの同時実行をブ ロックします。
Note: Automatically acquired by ALTER TABLE, DROP TABLE, VACUUM statements.
ALTER TABLE、 DROP 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 に よっても獲得されます。
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 つ の一般的なルールに従わなければなりません。
Transactions have to acquire locks on the same objects in the same order.
トランザクションは同じオブジェクトに同じ順番でロックを獲得する必 要があります。
For example, if one application updates row R1 and than updates row R2 (in the same transaction) then the second application shouldn't update row R2 if it's going to update row R1 later (in a single transaction). Instead, it should update rows R1 and R2 in the same order as the first application.
例えば、あるアプリケーションが(同じトランザクションの中で)R1 行を更新し、そして R2 行を更新する場合、別のアプリケーションは ( 1 つのトランザクションの中で)後で R1 行を更新する予定がある ならば、R2 行を更新してはいけません。その代わりに、最初のアプリ ケーションと同じ順番で R1 行と R2 行を更新しなければなりません。
Transactions should acquire two conflicting lock modes only if one of them is self-conflicting (i.e. may be held by one transaction at time only). If multiple lock modes are involved, then transactions should always acquire the most restrictive mode first.
トランザクションは、2 つのロックモードの内の 1 つがそのモード自身 とコンフリクトする場合(つまり同時に 1 つのトランザクションしかそ のロックを保持できない場合)にのみ、2 つのコンフリクトするロック モードを獲得しなければなりません。複数のロックモードが必要な場合 は、トランザクションは常に最も制限の強いモードをまず獲得しなけれ ばなりません。
An example for this rule was given previously when discussing the use of SHARE ROW EXCLUSIVE mode rather than SHARE mode.
このルールの例は、上の、SHARE モードよりも SHARE ROW EXCLUSIVE モ ードを使用すべきであるという議論にて記述しています。
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.
LOCK は Postgres の 拡張言語です。
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;