Provided by: manpages-zh_1.6.4.0-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
DESCRIPTION 描述
LOCK TABLE 獲取一個表級鎖，必要時等待任何衝突的鎖釋放。 一旦獲取了這個鎖，它就會在當前事務的餘下部分一直
保持。 （沒有 UNLOCK TABLE 命令；鎖總是在事務結尾釋放。）
在為那些引用了表的命令自動請求鎖的時候，PostgreSQL 總是儘可能使用最小限制的鎖模式。LOCK TABLE 是為你在
需要更嚴格的鎖的場合提供的。 例如，假設一個應用在讀已提交隔離級別上執行事務， 並且它需要保證在表中的資料
在事務的執行過程中都存在。要實現這個目的， 你可以在查詢之前對錶使用 SHARE 鎖模式進行鎖定。 這樣將保護資料
不被並行修改並且為任何更進一步的對錶的讀操作提供實際的當前狀態的資料， 因為 SHARE 鎖模式與任何寫操作需要
的 ROW EXCLUSIVE 模式衝突， 並且你的 LOCK TABLE name IN SHARE MODE 語句將等到所有並行的寫操作提交或回捲
後才執行。因此，一旦你獲得該鎖，那麼就不會存在未提交的寫操作．
如果執行在可序列化隔離級別並且你需要讀取真實狀態的資料時， 你必須在執行任何資料修改語句之前執行一個 LOCK
TABLE 語句。 一個可序列化事務的資料圖象將在其第一個資料修改語句開始的時候凍結住。 稍後的 LOCK TABLE 將仍
然阻止併發的寫 －－－ 但它不能保證事務讀取的東西對應最近提交的數值。
如果一個此類的事務準備修改一個表中的資料，那麼應該使用 SHARE ROW EXCLUSIVE 鎖模式，而不是 SHARE 模式。
這樣就保證任意時刻只有一個此類的事務執行。不這樣做就可能會死鎖： 當兩個並行的事務可能都請求 SHARE 模
式，然後試圖更改表中的資料時， 兩個事務在實際執行更新的時候都需要 ROW EXCLUSIVE 鎖模式， 但是它們無法再次
獲取這個鎖。（請注意，一個事務自己的鎖是從不衝突的， 因此一個事務可以在持有 SHARE 模式的鎖的時候請求 ROW
EXCLUSIVE 模式－－但是不能在任何其它事務持有 SHARE 模式的時候請求。） 為了避免死鎖，所有事務應該保證以相
同的順序對相同的物件請求鎖， 並且，如果涉及多種鎖模式，那麼事務應該總是最先請求最嚴格的鎖模式。
有關鎖模式和鎖定策略的更多資訊，請參考 Section 12.3 ``Explicit Locking'' 。
PARAMETERS 引數
name
要鎖定的現存表的名字（可以有模式修飾）。
命令 LOCK a, b; 等效於 LOCK a; LOCK b;。 表是按照 LOCK 命令中宣告的順序一個接一個順序上鎖的。
lockmode
鎖模式宣告這個鎖和那些鎖衝突。鎖模式在 Section 12.3 ``Explicit Locking'' 裡描述。
如果沒有宣告鎖模式，那麼使用最嚴格的模式 ACCESS EXCLUSIVE。
NOTES 注意
LOCK ... IN ACCESS SHARE MODE 需要在目標表上有 SELECT 許可權。所有其它形式的 LOCK 需要 UPDATE 和/或
DELETE 許可權。
LOCK 只是在一個事務塊的內部有用 （BEGIN...COMMIT），因為鎖在事務結束的時候馬上被釋放。 出現在任意事務塊外
面的 LOCK 都自動生成一個自包含的事務，因此該鎖在獲取之後馬上被丟棄。
LOCK TABLE 只處理表級的鎖，因此那些有 ROW 字樣的鎖都是用詞不當。這些模式名字通常應該應該理解為使用者檢視
在一個被鎖定的表中獲取行級的鎖。 同樣 ROW EXCLUSIVE 模式也是一個可共享的表級鎖。 我們一定要記住，只要是涉
及到 LOCK TABLE， 那麼所有鎖模式都有相同的語意，區別只是它們與哪種鎖衝突的規則。
EXAMPLES 例子
演示在往一個外來鍵表上插入時在有主鍵的表上使用 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;
在執行刪除操作時對一個有主鍵的表進行 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;
COMPATIBILITY 相容性
在 SQL 標準裡面沒有LOCK TABLE ，可以使用 SET TRANSACTION 來聲明當前事務的級別。 PostgreSQL 也支援這
個，參閱 SET TRANSACTION [set_transaction(7)] 獲取詳細資訊。
除了 ACCESS SHARE，ACCESS EXCLUSIVE，和 SHARE UPDATE EXCLUSIVE 鎖模式外， PostgreSQL 鎖模式和 LOCK
TABLE 語句都與那些在 Oracle 裡面的相容。
譯者
Postgresql 中文網站 何偉平 <laser@pgsqldb.org>
跋
本頁面中文版由中文 man 手冊頁計劃提供。
中文 man 手冊頁計劃：https://github.com/man-pages-zh/manpages-zh