?
This document uses PHP Chinese website manual Release
13.3. 明確鎖定
PostgreSQL提供了多種鎖模式用于控制對表中數(shù)據(jù)的并發(fā)訪問。 這些模式可以用于在MVCC無法給出期望行為的場合。 同樣，大多數(shù)PostgreSQL命令自動施加恰當(dāng)?shù)逆i以保證被引用的表在命令的執(zhí)行過程中 不會以一種不兼容的方式刪除或修改。 （例如，ALTER TABLE無法安全地執(zhí)行與同一表中上的其他操作以便獲取獨(dú)占鎖的表執(zhí)行的。）
要檢查的數(shù)據(jù)庫服務(wù)器中的當(dāng)前未解除鎖定的列表，可以使用pg_locks系統(tǒng)視圖。 有關(guān)監(jiān)控鎖管理器子系統(tǒng)狀態(tài)的更多信息，請參考Chapter 27。
13.3.1. 表級鎖
下面的列表顯示了可用的鎖模式和PostgreSQL自動使用它們的場合。 你也可以用 LOCK 命令明確獲取這些鎖。 請注意所有這些鎖模式都是表級鎖，即使它們的名字包含"row"單詞(這些名稱是歷史遺產(chǎn))。 從某種角度而言，這些名字反應(yīng)了每種鎖模式的典型用法，但是語意卻都是一樣的。 兩種鎖模式之間真正的區(qū)別是它們有著不同的沖突鎖集合(參考Table 13-2)。 兩個事務(wù)在同一時刻不能在同一個表上持有相互沖突的鎖。 不過，一個事務(wù)決不會和自身沖突。 比如，它可以在一個表上請求ACCESS EXCLUSIVE然后接著請求ACCESS SHAREE。 非沖突鎖模式許多事務(wù)可以同時持有。 請?zhí)貏e注意有些鎖模式是自沖突的(比如，在任意時刻ACCESS EXCLUSIVE模式就不能夠被多個事務(wù)擁有)， 但其它鎖模式都不是自沖突的(比如，ACCESS SHARE 可以由多個事務(wù)持有)。
表級鎖模式
- ACCESS SHARE
-
只與ACCESS EXCLUSIVE模式?jīng)_突。
SELECT命令獲取此模式被引用表上的鎖。 通常，任何查詢只讀取表而不修改它的命令都請求這種鎖模式。
- ROW SHARE
-
與EXCLUSIVE和ACCESS EXCLUSIVE鎖模式?jīng)_突。
SELECT FOR UPDATE和SELECT FOR SHARE命令在目標(biāo)表上需要一個這樣模式的鎖 （加上在所有被引用但沒有ACCESS SHARE的表上的FOR UPDATE/FOR SHARE鎖）。
- ROW EXCLUSIVE
-
與SHARE，SHARE ROW EXCLUSIVE，EXCLUSIVE，ACCESS EXCLUSIVE鎖模式?jīng)_突。
UPDATE，DELETE，INSERT命令自動請求這個鎖模式 （加上所有其它被引用的表上的 ACCESS SHARE 鎖）。通常，這種鎖將用來請求任何修改表中數(shù)據(jù)的命令。
- SHARE UPDATE EXCLUSIVE
-
與SHARE UPDATE EXCLUSIVE, SHARE,SHARE ROW EXCLUSIVE,EXCLUSIVE, ACCESS EXCLUSIVE鎖模式 沖突。 模式改變和運(yùn)行VACUUM并發(fā)的情況下，這個模式保護(hù)一個表。
VACUUM(不帶 FULL選項(xiàng)),ANALYZE,CREATE INDEX CONCURRENTLY命令請求這樣的鎖。
- SHARE
-
與ROW EXCLUSIVE，SHARE UPDATE EXCLUSIVE，SHARE ROW EXCLUSIVE，EXCLUSIVE，ACCESS EXCLUSIVE沖突。 這個模式避免表的并發(fā)數(shù)據(jù)修改。
CREATE INDEX(不帶 CONCURRENTLY 選項(xiàng))語句要求這樣的鎖模式。
- SHARE ROW EXCLUSIVE
-
與ROW EXCLUSIVE， SHARE UPDATE EXCLUSIVE， SHARE，SHARE ROW EXCLUSIVE，EXCLUSIVE，ACCESS EXCLUSIVE沖突。
任何PostgreSQL命令都不會自動請求這個鎖模式。
- EXCLUSIVE
-
與ROW SHARE，ROW EXCLUSIVE，SHARE UPDATE EXCLUSIVE，SHARE，SHARE ROW EXCLUSIVE，EXCLUSIVE， ACCESS EXCLUSIVE沖突。 這個模式只允許并發(fā) ACCESS SHARE 鎖，也就是說，只有對表的讀動作可以和持有這個鎖模式的事務(wù)并發(fā)執(zhí)行。
任何PostgreSQL命令都不會在用戶表上自動請求這個鎖模式。 不過，在某些操作的時候，會在某些系統(tǒng)表上請求它。
- ACCESS EXCLUSIVE
-
與所有模式?jīng)_突(ACCESS SHARE，ROW SHARE，ROW EXCLUSIVE，SHARE UPDATE EXCLUSIVE，SHARE，SHARE ROW EXCLUSIVE，EXCLUSIVE， ACCESS EXCLUSIVE)。這個模式保證其所有者(事務(wù))是可以訪問該表的唯一事務(wù)。
ALTER TABLE，DROP TABLE， TRUNCATE，REINDEX， CLUSTER，VACUUM FULL命令要求這樣的鎖。 在LOCK TABLE命令沒有明確聲明需要的鎖模式時，它是缺省鎖模式。
Tip: 【提示】只有ACCESS EXCLUSIVE阻塞SELECT (不包含FOR UPDATE/SHARE語句)。
一旦請求已獲得某種鎖，那么該鎖模式將持續(xù)到事務(wù)結(jié)束。 但是如果在建立保存點(diǎn)之后才獲得鎖，那么在回滾到這個保存點(diǎn)的時候?qū)⒘⒓瘁尫潘性摫４纥c(diǎn)之后獲得的鎖。 這與ROLLBACK取消所有保存點(diǎn)之后對表的影響的原則一致。 同樣的原則也適用于PL/pgSQL異常塊中獲得的鎖：一個跳出塊的錯誤將釋放在塊中獲得的鎖。
Table 13-2. Conflicting lock modes
| Requested Lock Mode | Current Lock Mode | |||||||
|---|---|---|---|---|---|---|---|---|
| ACCESS SHARE | ROW SHARE | ROW EXCLUSIVE | SHARE UPDATE EXCLUSIVE | SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE | |
| ACCESS SHARE | ? | ? | ? | ? | ? | ? | ? | X |
| ROW SHARE | ? | ? | ? | ? | ? | ? | X | X |
| ROW EXCLUSIVE | ? | ? | ? | ? | X | X | X | X |
| SHARE UPDATE EXCLUSIVE | ? | ? | ? | X | X | X | X | X |
| SHARE | ? | ? | X | X | ? | X | X | X |
| SHARE ROW EXCLUSIVE | ? | ? | X | X | X | X | X | X |
| EXCLUSIVE | ? | X | X | X | X | X | X | X |
| ACCESS EXCLUSIVE | X | X | X | X | X | X | X | X |
13.3.2. 行級鎖
除了表級鎖以外，還有行級鎖，它們可以是排斥的或是共享的。 特定行上的排斥行級鎖是在行被更新的時候自動請求的。該鎖一直保持到事務(wù)提交或者回滾。 行級鎖不影響對數(shù)據(jù)的查詢，它們只阻塞對同一行的寫入。
要在不修改某行的前提下請求該行上的一個排斥行級鎖，用SELECT FOR UPDATE選取該行。 請注意一旦我們請求了特定的行級鎖，那么該事務(wù)就可以多次對該行進(jìn)行更新而不用擔(dān)心沖突。
要在某行上請求一個共享的行級鎖，用SELECT FOR SHARE選取該行。 一個共享鎖并不阻止其它事務(wù)請求同一個共享的鎖。 不過，其它事務(wù)不允許更新、刪除、或者排斥鎖住持有共享鎖的行。 任何這么做的企圖都將被阻塞并等待共享鎖的釋放。
PostgreSQL不會在內(nèi)存里保存任何關(guān)于已修改行的信息，因此對一次鎖定的行數(shù)沒有限制。 不過，鎖住一行會導(dǎo)致一次磁盤寫，例如， 因?yàn)?tt class="COMMAND">SELECT FOR UPDATE將修改選中的行以標(biāo)記它們是鎖住的，所以會導(dǎo)致磁盤寫。
除了表級別和行級別的鎖以外，頁面級別的共享/排斥鎖也用于控制共享緩沖池中表頁面的讀/寫。 這些鎖在抓取或者更新一行后馬上被釋放。應(yīng)用程序員通常不需要關(guān)心頁級鎖，我們在這里提到它們只是為了完整。
13.3.3. 死鎖
顯式鎖定的使用可能會增加死鎖的可能性，死鎖是指兩個(或多個)事務(wù)相互持有對方期待的鎖。 比如，如果事務(wù) 1 在表 A 上持有一個排斥鎖，同時試圖請求一個在表 B 上的排斥鎖， 而事務(wù) 2 已經(jīng)持有表 B 的排斥鎖，而卻正在請求在表 A 上的一個排斥鎖，那么兩個事務(wù)就都不能執(zhí)行。 PostgreSQL能夠自動偵測死鎖條件并且會通過退出其中一個事務(wù)從而允許其它事務(wù)完成來解決這個問題。 具體哪個事務(wù)會被退出是很難預(yù)計的，而且也不應(yīng)該依靠這樣的預(yù)計。
要注意的是死鎖也可能會因?yàn)樾屑夋i而發(fā)生(即使是沒有使用顯式的鎖定)。 考慮如下情況，兩個并發(fā)事務(wù)在修改一個表。 第一個事務(wù)執(zhí)行了：
UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 11111;
這樣就在指定帳號的行上請求了一個行級鎖。然后，第二個事務(wù)執(zhí)行：
UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 22222; UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 11111;
第一個UPDATE語句成功地在指定行上請求到了一個行級鎖，因此它成功更新了該行。 但是第二個UPDATE語句發(fā)現(xiàn)它試圖更新的行已經(jīng)被鎖住了，因此它等待持有該鎖的事務(wù)結(jié)束。 事務(wù)二現(xiàn)在就在等待事務(wù)一結(jié)束，然后再繼續(xù)執(zhí)行?，F(xiàn)在，事務(wù)一執(zhí)行：
UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 22222;
事務(wù)一企圖在指定行上請求一個行級鎖，但是它得不到：事務(wù)二已經(jīng)持有這樣的鎖了。 所以它等待事務(wù)二完成。因此，事務(wù)一被事務(wù)二阻塞住了，而事務(wù)二也被事務(wù)一阻塞住了：這就是一個死鎖條件。 PostgreSQL將偵測這樣的條件并退出其中一個事務(wù)。
防止死鎖的最好方法通常是保證所有使用一個數(shù)據(jù)庫的應(yīng)用都以一致的順序在多個對象上請求鎖定。 在上面的例子里，如果兩個事務(wù)以同樣的順序更新那些行，那么就不會發(fā)生死鎖。 我們也要保證在一個對象上請求的第一個鎖是該對象需要的最高的鎖模式。 如果我們無法提前核實(shí)這些問題，那么我們可以通過在現(xiàn)場重新嘗試因死鎖而退出的事務(wù)的方法來處理。
只要沒有檢測到死鎖條件，事務(wù)將一直等待表級鎖或行級鎖的釋放。 這意味著一個事務(wù)持續(xù)的時間太長不是什么好事(比如等待用戶輸入)。
13.3.4. 咨詢鎖
PostgreSQL允許創(chuàng)建由應(yīng)用定義其含義的鎖。 這種鎖被稱為咨詢鎖，因?yàn)橄到y(tǒng)并不強(qiáng)迫其使用，而是由應(yīng)用來保證其正確的使用。 咨詢鎖可用于 MVCC 難以實(shí)現(xiàn)的鎖定策略。一旦持有咨詢鎖就將持續(xù)到明確釋放或會話結(jié)束。 不同于各種標(biāo)準(zhǔn)的鎖，咨詢鎖并不考慮事務(wù)的語意：在一個回滾的事務(wù)中獲得的咨詢鎖并不會被自動釋放， 同樣的，在一個失敗的事務(wù)中釋放的咨詢鎖仍將保持釋放。 同一個咨詢鎖可以被它自己的進(jìn)程多次獲得：對于每一個鎖定請求必須有一個相應(yīng)的釋放請求，這樣才能最終真正釋放該鎖。 如果某個會話已經(jīng)持有一個咨詢鎖，那么對該鎖的額外請求將總會成功，即使其它會話正在等候該鎖的釋放也是如此。 與PostgreSQL中其它鎖一樣， 可以在pg_locks系統(tǒng)視圖中查看當(dāng)前被會話持有的所有咨詢鎖。
咨詢鎖是從共享內(nèi)存池中分配的，共享內(nèi)存池的大小由max_locks_per_transaction和 max_connections配置參數(shù)決定。 千萬不要耗盡這些內(nèi)存，否則服務(wù)器將不能再獲取任何新鎖。 因此服務(wù)器可以獲得的咨詢鎖數(shù)量是有上限的，根據(jù)服務(wù)器的配置不同，這個限制可能是幾萬到幾十萬個。
咨詢鎖一般用于模擬常見于"平面文件"數(shù)據(jù)管理系統(tǒng)的悲觀鎖策略。 雖然可以用存儲在表中的一個特定標(biāo)志達(dá)到同樣的目的，但是使用咨詢鎖更快，還可以避免 MVCC 臃腫， 更可以在會話結(jié)束的時候由系統(tǒng)自動執(zhí)行清理工作。 在某些特定情況下，特別是查詢包括明確的排序或LIMIT子句的時候，由于 SQL 表達(dá)式求值順序的影響， 必須注意控制咨詢鎖的獲取。 例如：
SELECT pg_advisory_lock(id) FROM foo WHERE id = 12345; -- ok SELECT pg_advisory_lock(id) FROM foo WHERE id > 12345 LIMIT 100; -- danger! SELECT pg_advisory_lock(q.id) FROM ( SELECT id FROM foo WHERE id > 12345 LIMIT 100 ) q; -- ok
在上述查詢中，第二種形式是危險的，因?yàn)椴⒉灰欢ㄔ阪i定函數(shù)執(zhí)行之前應(yīng)用LIMIT。 這可能導(dǎo)致獲得某些應(yīng)用不期望的鎖，并因此在會話結(jié)束之前無法釋放。 從應(yīng)用的角度來看，將掛起這樣的鎖，雖然它們?nèi)匀辉?tt class="STRUCTNAME">pg_locks中可見。
提供的操作咨詢鎖函數(shù)在Table 9-61中描述。