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