解决方式

某一个长事务占用的锁尚未释放，新的个事务又申请相同对象的锁。
当达到lock_timeout设置的时间后，就会报这个错误。
客户端需要及时提交或回滚事务，长事务是非常消耗数据库资源的一种行为，请尽量避免。

--查看锁表情况
select locktype,relation::regclass as relation,virtualxid as vxid,transactionid as xid,virtualtransaction vxid2,pid,mode,granted from adb_locks where granted = 'f';
--查看执行时间大于5分钟的长事务
select datname,pid,usename,client_addr,query,backend_start,xact_start,now()-xact_start xact_duration,query_start,now()-query_start query_duration,state from adb_stat_activity where state<>$$idle$$ and now()-xact_start > interval $$5 min$$ order by xact_start;
--kill 长事务。2种方式如下（PID是上述sql语句查询出来的pid返回值）：
方法一：
SELECT adb_cancel_backend(PID);
这种方式只能kill select查询，对update、delete 及DML不生效)

方法二：
SELECT adb_terminate_backend(PID);
这种可以kill掉各种操作(select、update、delete、drop等)操作

如果在 adb_locks 中没有查到表相关的锁信息， 那么需要去各个 datanode 上查看是否有两阶段未完成的事务挂在那，查询视图：select * from adb_prepared_xacts;
根据 prepared 字段的时间值判断是否有异常的事务，所谓的异常，满足以下条件：

prepared 字段值显示的时间距离当前时间较长，比如超过单个语句预期的执行时间。
每次查询，始终是某些事务，一直存在。

一般来说，这些事务算是异常事务了。可以在各个节点上查询这个事务的状态：select adb_xact_status(50996670) ; ，参数值为 adb_prepared_xacts 中的 gid 值去掉 T。

如果事务在 GTMCOORD 上已经提交，则需要在本节点提交该事务：commit 'T784168121';
如果事务在 GTMCOORD 上未提交，则需要在本节点回滚该事务：rollback prepared 'T784168121';

上述操作需要在事务对应的 database 上执行，通过 adb_prepared_xacts 的 database 列值来决定。

可以用如下语句生成批量操作语句：

select 'rollback prepared '''||gid||''';'
from adb_prepared_xacts
where to_char(prepared,'yyyy-mm-dd hh24:mi') ='2020-01-01 14:30'
and database = 'db1';

原因说明

无