Provided by:
manpages-zh_1.5-1_all 
NAME
LOCK - 明確地鎖定一茠
SYNOPSIS
LOCK [ TABLE ] name [, ...] [ IN lockmode MODE ]
where lockmode is one of:
ACCESS SHARE | ROW SHARE | ROW EXCLUSIVE | SHARE UPDATE EXCLUSIVE
| SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE
DESCRIPTIONyz
LOCK TABLE 獲取一茠禫鷓瞗A必n時等待任何沖突的鎖釋放。 一旦獲取了這-
蚋瞗A它就會在當前事務的餘下部分一直保持。 （沒有 UNLOCK TABLE
命令；鎖總是在事務結尾釋放。）
在為那些引用了表的命令自動請求鎖的時唌APostgreSQL 總是盡可能使用最小-
制的鎖模式。LOCK TABLE 是為你在需n更嚴格的鎖的場合提供的。
例如，假設一蚗野峖b讀已提交隔離級別上運行事務， 並且它需-
n保証在表中的數據在事務的運行過程中都存在。n實現這茈堛滿A
你可以在查詢之前對表使用 SHARE 鎖模式進行鎖定。 這樣將保護數據不被並行-
蚹翵疇B為任何更進一步的對表的讀操作提供實際的當前狀態的數據， 因為
SHARE 鎖模式與任何寫操作需n的 ROW EXCLUSIVE 模式沖突， 並且你的 LOCK
TABLE name IN SHARE MODE
語句將等到所有並行的寫操作提交或回卷後才執行。因此，一旦你獲得該鎖，那麼就不會存在未提交的寫操作．
如果運行在可串行化隔離級別並且你需n讀取真實狀態的數據時，
你必須在執行任何數據蚹嚜y句之前運行一 LOCK TABLE 語句。 一-
茈i串行化事務的數據圖像將在其第一蚍稊改語句開始的時婛結住。 稍後的
LOCK TABLE 將仍然阻止並發的寫 －－－
但它不能保証事務讀取的東西對應最近提交的數C
如果一茼嘔的事務準備蚹鴾@茠矰云獐琚A那麼應該使用 SHARE ROW
EXCLUSIVE 鎖模式，而不是 SHARE 模式。 這樣就保証任意時刻只有一-
茼嘔的事務運行。不這樣做就可能會死鎖： 當兩茖疆瑼漕i能都請求 SHARE
模式，然後試圖更改表中的數據時， 兩茖b實際執行更新的時堀˙愯 ROW
EXCLUSIVE 鎖模式， 但是它拑L法再次獲取這蚋瞗C（請注意，一-
茖菑v的鎖是從不沖突的， 因此一茖i以在持有 SHARE 模式的鎖的時-
埣虼D ROW EXCLUSIVE 模式－－但是不能在任何其它事務持有 SHARE 模式的時-
埣虼D。）
為了避免死鎖，所有事務應該保証以相同的順序對相同的對象請求鎖，
並且，如果涉及多種鎖模式，那麼事務應該總是最先請求最嚴格的鎖模式。
有關鎖模式和鎖定策略的更多信息，請參考 Section 12.3 ``Explicit
Locking'' 。
PARAMETERS數
name n鎖定的現存表的名字（可以有模式袡╮^。
命令 LOCK a, b; 等效於 LOCK a; LOCK b;。 表是按照 LOCK
命令中聲明的順序一荓竣@荈陽W鎖的。
lockmode
鎖模式聲明這蚋磡M那些鎖沖突。鎖模式在 Section 12.3 ``Explicit
Locking'' 裏描z。
如果沒有聲明鎖模式，那麼使用最嚴格的模式 ACCESS EXCLUSIVE。
NOTES`N
LOCK ... IN ACCESS SHARE MODE 需n在目標表上有 SELECT 權。所有其它形式的
LOCK 需n UPDATE 和/或 DELETE 權。
LOCK 只是在一茖籅漱熙’野
（BEGIN...COMMIT），因為鎖在事務結束的時埶角W被釋放。
出現在任意事務塊外悸 LOCK 都自動生成一-
茼菪]含的事務，因此該鎖在獲取之後馬上被丟棄。
LOCK TABLE 只處理表級的鎖，因此那些有 ROW
字樣的鎖都是用詞不當。這些模式名字通常應該應該理解為使用者視圖在一-
茬Q鎖定的表中獲取行級的鎖。 同樣 ROW EXCLUSIVE 模式也是一-
茈i共享的表級鎖。 我怳@定n記住，只n是涉及到 LOCK TABLE，
那麼所有鎖模式都有相同的語意，區別只是它抳P種鎖沖突的規則。
EXAMPLESl
演示在往一茈~鍵表上插入時在有主鍵的表上使用 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
INSERT INTO films_user_comments VALUES
(_id_, 'GREAT! I was waiting for it for so long!');
COMMIT WORK;
在執行刪除操作時對一茼野D鍵的表進行 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;
COMPATIBILITYe性
在 SQL 標準裏惆S有LOCK TABLE ，可以使用 SET TRANSACTION
來聲明當前事務的級別。 PostgreSQL 也支持這荂A參閱 SET TRANSACTION
[set_transaction(7)] 獲取詳細信息。
除了 ACCESS SHARE，ACCESS EXCLUSIVE，和 SHARE UPDATE EXCLUSIVE
鎖模式外， PostgreSQL 鎖模式和 LOCK TABLE 語句都與那些在 Oracle 裏-
悸漪萛e。
者
Postgresql <laser@pgsqldb.org>