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