【DWS】作业时长超过statement timeout后报错

【问题描述】作业statement timeout设置两个小时，两小时十四分钟后作业超市报错

【问题分析】

statement timeout定时器的触发时间计算方式为（stmtStartTimestamp + timeout），timeout是guc参数，设置以后可以看为固定值，而stmtStartTimestamp 在有些场景启动statement timeout定时器时会更新为当前时间，有些场景启动statement timeout定时器时不会更新，使用旧的stmtStartTimestamp 。

家里复现后，观察日志，w报文处理过程中启动statement timeout定时器使用旧的stmtStartTimestamp值， 多个statement timeout定时器的触发时间是相同的，即timer1、timer2 ... timerN的触发时间是相同的；
timerN定时器的触发时间跟当前时间非常接近，甚至晚于当前时间，导致timerN很快触发，报错statement timeout

问题场景梳理：
1. 设置statement timeout = 1h；
2. 连接cn5001执行sql文件脚本。
3. cn 5003为ccn角色。
4. 脚本里的语句类型顺序特征包含 DDL -> 较长时间DML -> DDL -> 较长时间DML  这样的特征 

问题还原：
1. 之前的批作业使得 cn5001会先和ccn cn5003建立连接（这里命名connect1)
2. 执行本批作业。 连接 cn5001执行本批作业的DDL+DML时，会建立新的连接，没用到connect1。
3. 经过一个小时以后，connect1闲置时间会大于等于1h。
4. 而后当cn5001通过connect1给cn5003发了一个DROP TABLE DDL的命令，此时cn5003的这个语句的定时器的起始时间没有更新为当前时间，使用的是connect1建立的时间，定时器经过计算后，判定语句执行时间超过1小时，触发超时报错（也就是触发process interrupt报错），而后事务回滚。
5. cn5003触发报错以后，上报错误给cn5001，对整个分布式其余正在执行的DROP TABLE DDL的节点下发事务回滚命令。

问题根因一句话总结：定时器的起始时间在部分场景下出现没有及时更新为当前时间的情况；

【规避措施】

1  设置 enable_force_reuse_connections  =  true    
2  关闭statement_timeout，部署外部查杀脚本替代定时查杀的功能
3  设置cache_connection=false