PostgreSQL死鎖的原因是什么

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

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

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

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

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

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

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

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

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

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

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

我們啟動兩個session 其中一個

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í)行語句前面的序號

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

系統(tǒng)會給出死鎖的信息以及相關(guān)解決的信息，當(dāng)然如果在死鎖期間，通過語句你也是可以發(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;

反過來我們?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

查看上面的日志

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

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

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

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

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