记一次简单的Postgresql阻塞处理

今日接到其他部门同事求助，说一条修改字段类型的alter语句执行很久也不结束。
登录到服务器查看进程情况：

SELECT pid, usename, datname, query, state, query_start 
FROM pg_stat_activity 
WHERE state = 'active' 
AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start;

找到了目标进程，看到state一列为active。
我的第一反应是表数据量大，可能要等一会儿。
但是再一看query_start发现这个进程已经执行5天了，看了下表数据量才不到200G，应该是有异常等待，遂继续排查。

检查表perception的对象id：

select * from pg_class where relname = 'perception';
select oid from pg_class where relname = 'perception';

然后根据oid检查锁情况：

select * from pg_locks where relation=21845;

或两步合为一步：

select * from pg_locks where relation= (select oid from pg_class where relname='perception');

然后发现granted一列果然没有拿到锁，而另一个idle的进程持有共享锁。
和同事沟通后，根据pid将目标进程杀掉：

SELECT pg_terminate_backend(1799232);

然后再次检查：

SELECT a.pid, a.state, a.query 
,b.locktype,b.mode,b.granted
FROM pg_stat_activity a
inner join pg_locks b
on a.pid = b.pid 
where b.relation =21845

发现我同事跑的alter已拿到排他锁，并顺利执行中。

SELECT a.query_start ,a.wait_event_type,a.wait_event,a.state,a.query
FROM pg_stat_activity a
where pid = 1787436

最终几十分钟执行完成。

在此做一下记录，以便日后对排障过程进行优化。