Provided by: manpages-zh_1.5-1_all bug

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>