现状描述：
最近部署了一套greenplum集群，但是在master上执行select语句时，出现夯住的情况，navicate客户端无任何响应，1h后超过默认重试时长报错如下：
WARNING: interconnect may encountered a network error, please check your network (seg1 slice1 10.10.x.xx:6001 pid=29745)
DETAIL: Failed to send packet (seq 1) to 10.10.x.xx:65239 (pid 31655 cid -1) after 100 retries.
使用java程序连接执行现状一致！
解决过程：
1.首先，验证各个服务器之间ssh服务是否正常，互信是否正常，这里还真发现点问题。当初配置互信时，$ gpssh-exkeys -f hostfile_exkeys就执行失败了，后来是手动配置的互信，并且ssh登录没问题。但是ssh到目标服务器时会报出警告提示ESDAhostkey问题，经过排查，发现/etc/ssh/ssh_config配置文件中多出两行配置：
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
这样便不会在ssh目录生成hosts文件，而gpssh-exkeys是要使用此文件的，所以手动删除这两行并重启ssh服务：systemctl restart sshd.service
2.第一步处理完毕后，$ gpssh-exkeys -f hostfile_exkeys执行通过，这个问题解决了，但是执行sql仍然夯住，问题依旧！看来并不是它的问题，于是查看master日志：vi /data/master/gpseg-1/pg_log/xxx.csv.(日志好多但是并无卵用......)
3.网上搜索了一下，并没有找到相关解决方案，自己评估了一下，重新部署一套应该不会太久，于是停库，删文件，重建部署！
4.顺便提一下，我部署的greenplum版本为greenplum-db-6.10.1。经过重新部署后，问题依旧！！这下就奇葩了，不过也是好事，起码排除了是部署原因导致的。我又仔细开始看第一步提到的报错：DETAIL: Failed to send packet (seq 1) to 10.10.x.xx:65239 (pid 31655 cid -1) after 100 retries.这个IP地址是master地址，说明命令可以由master下发给segment(从日志中也能看出)，但是无法回传。这说明要么是数据库本身的bug，要么是网络问题！
5.可惜网络协议本人不是很精通，于是开始以bug和网络协议等关键词为线索在线搜索，其中有一篇文章有如下说法：“GPDB默认使用的是UDP连接，GPDB 基于UDP实现了拥塞控制，能最大限度上提升性能，称为udpifc”，而且改文章还提到“开源Greenplum Database udpifc 的BUG，会导致Hang住”。这个文章是我要找的，仔细阅读！
6.文中提到一种解决方案：“切换到TCP，不再使用udpifc: 将GUC参数gp_interconnect_type设置为tcp即可。”很好，那就切换协议试试，于是执行如下语句尝试查看并修改参数：
gpconfig --show gp_interconnect_type
结果，查看参数语句像sql语句一样夯住了！杀掉：
select * from pg_stat_activity where state ='active';
select pg_cancel_backend(32709);
直接修改参数：gpconfig -c gp_interconnect_type -v tcp
好的，又挂住了......
7.虽然参数无法使用命令修改参数，但是我觉得修改网络协议的思路是对的，于是在greenplum的各个配置文件中寻找此参数，找到了，它在文件postgresql.conf中，于是直接在文件中改：
# vi /data/master/gpseg-1/postgresql.conf
gp_interconnect_type=udpifc --> gp_interconnect_type=tcp
所有机器都要改，不过segment服务器此配置文件位置有所不同，要注意下。
修改完毕后重启数据库：$ gpstop -r
问题解决了！！
事后在官方查看相关文档，发现就是一个bug，新版本已解决。
