DWS语句处于idle in transaction状态常见场景

idle in transaction在pg_stat_activity中的状态解释是：后端语句在事务中，但事务中没有语句在执行。该状态表示该条语句已经执行完成，因此query_id为0，但是本事务还未提交或回滚。此状态下的语句已经执行完成，不占用CPU和IO等资源，会占用连接数，并发数等连接资源。

通常有以下几种场景：

1. 常见场景一：事务开启后没有提交

手动begin/start transaction开启事务，执行语句后，不执行commit/rollback，此时查看活跃视图pgxc_stat_activity，可以看到state为idle in transaction：

解决方法：这种场景下需要手动对开启的事务commit/rollback即可。

2.常见场景二：存储过程中有DDL语句，该存储过程结束前，其他节点上DDL语句执行完后的状态是idle in transaction

创建如下存储过程：

CREATE OR REPLACE FUNCTION public.test_sleep()
RETURNS void
LANGUAGE plpgsql
AS $$

BEGIN
	truncate t1;
    truncate t2;
    EXECUTE IMMEDIATE 'select pg_sleep(6)';
	RETURN;
END$$;

执行该语句，查看pgxc_stat_activity活跃视图，truncate t2处于idle in transaction状态，coorname为coordinator2，说明cn2上该语句已经执行完成，该存储过程在执行下一条语句：

解决方法：此类场景是由于存储过程执行慢导致，等存储过程执行完成即可，也可考虑优化存储过程中执行时间较长的语句。

3.常见场景三：大量savepoint/release语句处于idle in transaction（8.1.0以前版本）

此类语句是带EXCEPTION的存储过程执行时自动加入的，GaussDB带Exception的存储过程在实现上基于子事务实现，简单对应关系如下：

begin
    (Savepoint s1)
    DDL/DML
exception
    (Rollback to s1)
    (Release s1)
     …
end

可参考：https://bbs.huaweicloud.com/forum/thread-105887-1-1.html。

解决方法：savepoint和release等语句是带exception的存储过程自动生成的（8.1.0以后的版本不再给CN下发savepoint），当此类存储过程较多且有嵌套是容易出现，与场景二类似，等整个存储过程执行完即可，如果release较多，说明存储过程出发了多个exception，可分析存储过程逻辑是否合理。

4.常见场景四：事务提交慢

此类场景多见于DN上出现，CN上语句是active，DN上语句处于idle in transaction，此类场景多见于DN上存在Catchup的时候，主备同步慢导致某个DN事务提交慢。

解决方法：参考集群长时间Catchup案例，优先解决Catcup问题。