GreenPlum死锁问题定位手记

问题描述

• GreenPlum 5.0版本，在使用 gpcrondump 做备份时，如果同时还在执行一个自己写的存储过程，就有很高概率导致数据库死锁
• 该存储过程中涉及到表的创建、删除、数据导入等动作

分析过程

• 因对GPDB以及Postgresql都不太熟，先在网上搜索了下“GreenPlum 死锁”，果真找到一篇定位过程分享 ，作者写的非常详细，几乎是手把手、图文并茂的讲述了他排查GPDB死锁的过程。参考该文章，定位步骤如下：
  
  1. 待问题重现时,从 pg_stat_activity 表中查找处于等锁状态的任务:
     select * from pg_stat_activity where waiting_reason='lock';

template1=# select * from pg_stat_activity where waiting_reason='lock';
 datid | datname | procpid | sess_id | usesysid | usename |                           current_query                           | waiting |          query_start          |         backend_start         | client_addr | client_port | application_name |          xact_start  
         | waiting_reason | rsgid | rsgname | rsgqueueduration 
-------+---------+---------+---------+----------+---------+-------------------------------------------------------------------+---------+-------------------------------+-------------------------------+-------------+-------------+------------------+----------------------
---------+----------------+-------+---------+------------------
 97128 | dsst    |     923 |     244 |       10 | gpadmin | truncate c_picrecord_1_prt_extra ;                                | t       | 2017-12-11 15:10:18.840394+08 | 2017-12-08 16:57:48.826455+08 |             |          -1 | psql             | 2017-12-11 15:10:18.8
40394+08 | lock           |     0 |         | 
 97128 | dsst    |   20528 |     393 |       10 | gpadmin | SELECT pg_get_partition_def('97147'::pg_catalog.oid, true, true)  | t       | 2017-12-11 15:10:25.10717+08  | 2017-12-11 15:10:24.877717+08 |             |          -1 |                  | 2017-12-11 15:10:24.8
90674+08 | lock           |     0 |         | 
(2 rows)

1. 可见truncate c_picrecord_1_prt_extra和SELECT pg_get_partition_def('97147'::pg_catalog.oid, true, true)两个任务死锁了。
   前者就是我们自己写的存储过程中的一个步骤;后者是数据库备份过程中自动产生的任务。
2. 关联pg_locks,pg_class,pg_stat_activity 表，查询与上述任务相关的锁。这里我们按照存储过程中使用的表名称过滤&