在greenplum中使用psql执行sql，报网络异常错误。

Question

环境：

6台机子做greenplum集群，在主节点上运行sh脚本

问题描述

在执行

psql -h localhost -p 2345 -Ugpadmin crm_analy -f /home/gpadmin/crm_topic/channel_flow_analysis_sql_do.sql

命令时会偶发以下错误：

ERROR: Interconnect encountered a network error, please check your network (seg3 slice1 gp2.ops.bj1:33001 pid=69361)
DETAIL: Failed to send packet (seq 1) to 10.0.3.33:56292 (pid 37236 cid 6) after 3580 retries in 3600 seconds

看错误是由于网络错误引起的，我们检查了网络，没有发现问题。
并且此错误会一直重试一个小时后报错。

问题

1、此错误是否是由于节点间的网络问题引起的？
2、若是由于节点间网络问题引起的，为什么有“3580 retries in 3600 seconds”，在这一个小时内网络都会有问题？
3、要是不是由于节点间网络问题引起的，那有可能是怎么引起的，有什么解决方式？

---

不胜感激！

Answer 1

从错误信息上看，是网络原因引起的。

但是这不代表你的网络不通了，如果你检查网络连通性的话，可能发现不了问题。原因是，GPDB默认使用的是UDP连接，GPDB 基于UDP实现了拥塞控制，能最大限度上提升性能，称为udpifc。

3600秒是udpifc默认的超时，在这段时间内，udpifc 会尝试不断的重发丢失的包。直到超时为止。

回答你的问题。
1） 是的，是网络问题。
2） 已经解释过超时和重试了。
3） 我们在开发测试和用户实际使用的经验中，遇到过以下情况。

a) XX品牌的交换机在压力大的时候直接丢弃 UDP 的包。
b) XX云的虚拟网络的BUG，导致UDP丢包。
c) 网卡MTU设置过大，导致丢包。
d) 开源Greenplum Database udpifc 的BUG，会导致Hang住（已经修复）。

解决方案：

a) 切换到TCP，不再使用udpifc: 将GUC参数gp_interconnect_type设置为tcp即可。如果集群过大或者并发较多，可能会有扩展性问题。
b) 确定 UDP 丢包的原因，可以使用tcpdump等工具定位问题，解决网络问题。
c) 使用GPDB的稳定版本，不要使用开源版本，开源版本的GPDB正在为第一个稳定版 5.0 release 奋斗，现在还不稳定。 稳定版GPDB 4.3.xx 可以从Pivotal官方下载。

利益相关：
本人为HashData工作，HashData 提供GPDB稳定企业版，并提供GPDB的咨询和支持服务。

Answer 2

我将参数改为tcp,数据插入较快，但是数据查询很慢或者说无法查询这个问题如何解决