PostgreSQL9.6：新增pg_blocking_pids函數準肯定位 Blocking SQL

PosttgreSQL 的SQL被鎖狀況在數據庫維護過程當中很是常見，以前博客 PostgreSQL 鎖分析 演示了 PostgreSQL 鎖的一些場景，在開始本文的介紹以前特作如下說明，假如會話A堵住會話B，咱們稱會話B爲 blocked 會話，會話A爲 blokcing 會話，後續介紹時都用這兩個詞；當數據庫出現鎖時，若是對應用有影響，DBA應該在最短的時間內找到 blocking 會話並快速處理，在 9.6 版本前查找 blocking SQL 一般須要查詢 pg_stat_activity、 pg_locks 等一系列視圖，增長了故障分析的時間，9.6 版本新增 pg_blocking_pids() 函數，可以快速找到 blocking SQL，下面模擬一個簡單的場景介紹這個函數的使用。

--建立測試表

francs=> create table test_lock(id int4,name text);
CREATE TABLE

francs=> insert into test_lock values(1,'a'),(2,'b'),(3,'c');
INSERT 0 3

--會話一

francs=> select pg_backend_pid();
 pg_backend_pid 
----------------
          22814
francs=> begin;
BEGIN
          
francs=> update test_lock set name='cc' where id=3;
UPDATE 1

備註：會話一在事務裏更新 ID=3 的記錄，並不提交。

--會話二

francs=> select pg_backend_pid();
 pg_backend_pid 
----------------
          22845
(1 row)

francs=> delete from test_lock where id=3;

備註：會話二刪除ID=3的記錄，此時因爲這條記錄以前被UPDATE並無提交，這句DELETE仍然處於等待狀態。

--監控

備註：從圖中看到以前操做的兩條 SQL，爲何 22845 會話處於等待狀態呢，運行 pg_blocking_pids 函數能夠找到 blocking 會話，以下：

--查找 blocking SQL

postgres=# select pg_blocking_pids(22845);
 pg_blocking_pids 
------------------
 {22814}
(1 row)

備註：22814 正是 blocking SQL， 22845 爲 blocked SQL。

--總結

這篇博客僅模擬了一個簡單場景，並經過 pg_blocking_pids 函數查找 blocking
SQL，真實生產環境鎖的案例遠比這複雜，具體狀況具體分析。

--參考
PostgreSQL 鎖分析