问题描述
- GreenPlum 5.0版本,在使用 gpcrondump 做备份时,如果同时还在执行一个自己写的存储过程,就有很高概率导致数据库死锁
- 该存储过程中涉及到表的创建、删除、数据导入等动作
分析过程
- 因对GPDB以及Postgresql都不太熟,先在网上搜索了下“GreenPlum 死锁”,果真找到一篇定位过程分享 ,作者写的非常详细,几乎是手把手、图文并茂的讲述了他排查GPDB死锁的过程。参考该文章,定位步骤如下:
- 待问题重现时,从 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)
- 可见
truncate c_picrecord_1_prt_extra
和SELECT pg_get_partition_def('97147'::pg_catalog.oid, true, true)
两个任务死锁了。
前者就是我们自己写的存储过程中的一个步骤;后者是数据库备份过程中自动产生的任务。
- 关联
pg_locks
,pg_class
,pg_stat_activity
表,查询与上述任务相关的锁。这里我们按照存储过程中使用的表名称过滤&