這篇文章主要講解了“PostgreSQL死鎖的原因是什么”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“PostgreSQL死鎖的原因是什么”吧！

創(chuàng)新互聯(lián)長(zhǎng)期為上1000家客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對(duì)不同對(duì)象提供差異化的產(chǎn)品和服務(wù)；打造開(kāi)放共贏平臺(tái)，與合作伙伴共同營(yíng)造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為綏濱企業(yè)提供專業(yè)的成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作、外貿(mào)網(wǎng)站建設(shè)，綏濱網(wǎng)站改版等技術(shù)服務(wù)。擁有十余年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開(kāi)發(fā)。

任何數(shù)據(jù)庫(kù)都有死鎖，MySQL的死鎖有相關(guān)的工具，或者去日志查找，postgresql的死鎖又怎么搞，今天的來(lái)說(shuō)說(shuō)。

首先來(lái)說(shuō)postgresql 檢測(cè)死鎖在配置文件中是有相關(guān)配置的，在postgresql中有三個(gè)和查詢有關(guān)的超時(shí)設(shè)置

deadlock_timeout
進(jìn)行死鎖檢測(cè)之前在一個(gè)鎖上等待的總時(shí)間

lock_timeout
鎖等待超時(shí)。語(yǔ)句在試圖獲取表、索引、行或其他數(shù)據(jù)庫(kù)對(duì)象上的鎖時(shí)等到超過(guò)指定的毫秒數(shù)，該語(yǔ)句將被中止。不推薦在postgresql.conf中設(shè)置。

statement_timeout
控制語(yǔ)句執(zhí)行時(shí)長(zhǎng)，單位是ms。超過(guò)設(shè)定值，該語(yǔ)句將被中止。 

這三個(gè)里面的設(shè)置，死鎖的檢測(cè)一定是要設(shè)置的，因?yàn)樗梨i被發(fā)現(xiàn)時(shí)，最好是盡快的通過(guò)系統(tǒng)檢測(cè)到后，盡快的解除（犧牲一個(gè)）。保證系統(tǒng)正常的運(yùn)行，尤其在OLTP的系統(tǒng)中。所以這里一般可以設(shè)置一個(gè)較短的值，例如1秒。

lock_timeout 這個(gè)屬于 A 有 B 的資源，B需要等待A 的資源釋放后等待可以忍受的時(shí)間，一般來(lái)說(shuō)，如果不是故意例如 寫(xiě)完begin 后不操作 commit,任務(wù)很快的完成的情況下，一般來(lái)說(shuō)我們不設(shè)置 lock_timeout ，當(dāng)然如果在一個(gè)糟糕的系統(tǒng)中，經(jīng)常發(fā)生霸占資源不釋放的狀態(tài)，這樣的不設(shè)置也可以很快發(fā)現(xiàn)問(wèn)題。（稍后會(huì)給出語(yǔ)句）。

statement_timeout 類似于MYSQL 也有類似的設(shè)置或者通過(guò)PT工具來(lái)進(jìn)行設(shè)置，將超過(guò)運(yùn)行設(shè)定時(shí)間的語(yǔ)句，KILL掉，這里面我們也是一般不進(jìn)行設(shè)置的。

不進(jìn)行設(shè)置默認(rèn)是一直等待。

OK 我們先來(lái)看一下什么是死鎖，這里我們稍微的把死鎖的鑒定的時(shí)間調(diào)大一點(diǎn)，好來(lái)給執(zhí)行發(fā)現(xiàn)死鎖的語(yǔ)句一點(diǎn)時(shí)間，我們將deadlock_timeout 設(shè)置為 20秒，當(dāng)然如果是生產(chǎn)系統(tǒng)，你這樣做，呵呵 你還想干嗎？

我們啟動(dòng)兩個(gè)session 其中一個(gè)

Session 1

1  test=# begin;

BEGIN

2  test=# update test set value = 'tyyu' where id =3;

UPDATE 1

5 test=# update test set value = 'tyyu' where id =2;

Session 2

3  test=# begin;

BEGIN

4 test=# update test set value = 'tyyu' where id =2;

UPDATE 1

6 test=# update test set value = 'tyyu' where id =3;

大家可以看我的執(zhí)行語(yǔ)句前面的序號(hào)

在系統(tǒng)里面等待20秒后

系統(tǒng)會(huì)給出死鎖的信息以及相關(guān)解決的信息，當(dāng)然如果在死鎖期間，通過(guò)語(yǔ)句你也是可以發(fā)現(xiàn)相關(guān)的死鎖信息的。

SELECT blocked_locks.pid     AS blocked_pid,

         blocked_activity.usename  AS blocked_user,

         blocking_locks.pid     AS blocking_pid,

         blocking_activity.usename AS blocking_user,

         blocked_activity.query    AS blocked_statement,

         blocking_activity.query   AS current_statement_in_blocking_process

   FROM  pg_catalog.pg_locks         blocked_locks

    JOIN pg_catalog.pg_stat_activity blocked_activity  ON blocked_activity.pid = blocked_locks.pid

    JOIN pg_catalog.pg_locks         blocking_locks 

        ON blocking_locks.locktype = blocked_locks.locktype

        AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE

        AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation

        AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page

        AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple

        AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid

        AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid

        AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid

        AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid

        AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid

        AND blocking_locks.pid != blocked_locks.pid

     JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid

   WHERE NOT blocked_locks.GRANTED;

反過(guò)來(lái)我們?nèi)ゲ榭慈罩?/p>

CST [15798] LOG:  duration: 74.150 ms

CST [15788] LOG:  process 15788 detected deadlock while waiting for ShareLock on transaction 678 after 20003.487 ms

CST [15788] DETAIL:  Process holding the lock: 15786. Wait queue: .

CST [15788] CONTEXT:  while updating tuple (0,3) in relation "test"

 [15788] STATEMENT:  update test set value = 'tyyu' where id =3;

CST [15788] ERROR:  deadlock detected

CST [15788] DETAIL:  Process 15788 waits for ShareLock on transaction 678; blocked by process 15786.

Process 15786 waits for ShareLock on transaction 679; blocked by process 15788.

Process 15788: update test set value = 'tyyu' where id =3;

Process 15786: update test set value = 'tyyu' where id =2;

CST [15788] HINT:  See server log for query details.

CST [15788] CONTEXT:  while updating tuple (0,3) in relation "test"

CST [15788] STATEMENT:  update test set value = 'tyyu' where id =3;

CST [15786] LOG:  duration: 12131.851 ms

查看上面的日志

通過(guò)上面的日志給出的信息 process 15788 檢測(cè)到死鎖，在20秒的時(shí)候，（20003.487）15788 等 待sharelock 鎖，而process 15788 被 15786 kill 掉。在最后踢掉的過(guò)程中， 15788  的語(yǔ)句是 update test set value = 'tyyu' where id =3;  15786 的語(yǔ)句是 

update test set value = 'tyyu' where id =2;

在PG 中有行鎖和表鎖兩種，每行記錄都有xmax， 如果一個(gè)事務(wù)要處理這一行會(huì)在 XMAX 上添加 transaction_ID, 如果這樣一行已經(jīng)有了 transaction_id 則要再次添加事務(wù)ID 的事務(wù)就需要等待。而當(dāng)要進(jìn)行UPDATE 和 DELETE 操作的過(guò)程中會(huì)檢查相關(guān)行的 XMAX 的狀態(tài)。

通過(guò)判斷XMAX 的狀態(tài)來(lái)，這條記錄可以被UPDATE 或者 DELETE 還是不能。這也是POSTGRESQL 和別的數(shù)據(jù)庫(kù)比較沒(méi)有UNDO 這個(gè)空間的設(shè)置原因之一，因?yàn)椴恍枰?/p>

感謝各位的閱讀，以上就是“PostgreSQL死鎖的原因是什么”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)PostgreSQL死鎖的原因是什么這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！

文章名稱：PostgreSQL死鎖的原因是什么
轉(zhuǎn)載來(lái)于：http://www.rwnh.cn/article40/pgseeo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站內(nèi)鏈、網(wǎng)站設(shè)計(jì)公司、品牌網(wǎng)站設(shè)計(jì)、定制網(wǎng)站、小程序開(kāi)發(fā)、

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)