Analysis and Solution of PostgreSQL9.5 Database Lock Table Problem

//查询锁表的情况
SELECT A.locktype,A.DATABASE,A.pid,A.mode,b.relname FROM pg_locks A JOIN pg_class b ON A.relation = b.oid;
//杀死进程 
select pg_terminate_backend(pid); //pid为进程id号
//用于查询系统进程状态的表
select * from pg_stat_activity;
主要关注waiting 是否等待中，stat 进程状态， query 具体语句
当waiting 为t 的进行需要特别注意，query可以查看到具体语句，然后进行查杀

// The table used to query the status of the system process
select * from pg_stat_activity;
Mainly concerned about whether waiting is waiting, stat process status, query specific statement
When waiting for t needs special attention, query can view specific statements and then kill
The final reason is that mq congestion caused some processes to go, and the code process involves operations such as updates, and database locks have always occupied the connection resources.

/* NoLock is not a lock mode, but a flag value meaning "don't get a lock" */
#define NoLock                          0
#define AccessShareLock                 1 /* SELECT */
#define RowShareLock                    2 /* SELECT FOR UPDATE/FOR SHARE */
#define RowExclusiveLock                3 /* INSERT, UPDATE, DELETE */
#define ShareUpdateExclusiveLock        4 /* VACUUM (non-FULL),ANALYZE, CREATE
                                           * INDEX CONCURRENTLY */
#define ShareLock                       5 /* CREATE INDEX (WITHOUT CONCURRENTLY) */
#define ShareRowExclusiveLock           6 /* like EXCLUSIVE MODE, but allows ROW
                                           * SHARE */
#define ExclusiveLock                   7 /* blocks ROW SHARE/SELECT...FOR
                                           * UPDATE */
#define AccessExclusiveLock             8 /* ALTER TABLE, DROP TABLE, VACUUM
                                           * FULL, and unqualified LOCK TABLE */

From: https://www.cnblogs.com/zluckiy/p/12486838.html