收到业务侧反馈有一个存储过程无法执行在启动一分钟左右，会报错。
如图所示报错信息could not temporarily connect to one or more segments
翻译过来是“暂时无法连接到一个或多个段”，段在这里就是实例。
第一反应是不是有实例宕了，gpstate -e查看数据库状态。
一切正常，没有实例宕停的情况出现。但是报错信息除了告诉我们无法连接到某个实例之外，也没有什么有用的信息。（其实，有一个提示很重要但是当时没有在意，那就是“line 105”）
看下数据库日志，并询问业务一些信息，如是否是新上线的调度，insert select所涉及的表有多大，是只有这一个调度无法执行还是所有的都无法执行。
得到以下几点信息：
一：调度是之前上线的，突然无法执行。
二：涉及的表数据略大具体多少不清楚，但是同样的数据量，同样的调度在另一套只有10台主机备库是可以正常跑过的。
三：只有这一个调度有问题。
数据库日志如下：
报错内容与前台给的差不多。百度谷歌也没有搜到有用的消息。
此时看集群资源使用率在三四十左右，且此调度数据量较大。建议业务减少关联表，并在资源空闲时执行调度测试。
同时看下是否是连接数过多的原因。此参数在master上最大是250，在segment上最大是750。
Segment主机实例的连接数。
Master主机的连接数
看来跟连接数没什么关系，业务侧也回复，在资源使用空闲时执行还是报错。并且他们不方便改存储过程，希望我侧尽力解决这个问题。
好吧，再看一下报错信息，有个”line 105”。将存储过程导出，看看105行是什么。
psql -c “\df+ functionname” > ~/function.txt
一共union all 24张表，后面没有截全。
这应该是提示从这里开始报错的。此时还没有想到什么办法，一边请教原厂售后，另一边想看下这些表的数据量和表结构。于是select count(1) from tablename;
将24张表count一遍发现了异常。
这几张表都报了数据块错误，会不会是因为这个错误导致调度执行不了？
手动处理了一下，具体步骤略，如果不会处理这个错误可以重建表解决。
处理完验证没有问题，再此联系业务测试，还是不行。此时陷入了僵局，似乎没有什么办法解决了。
原厂售后工程师也回复，看下segment节点有没有panic，一般这样的报错是segment有panic导致连接突然中断。并且表示生产库的版本遇到这样的问题没有什么解决办法，只能绕过。
看下segment的数据库日志。
还是有数据块报错，但是count表是正常的。找一下这个数据块属于那张表。
这张表是heap表，并且常规方法无法处理。联系业务侧重建并测试。
重建后再次执行成功。
注：如果是使用gptransfer和copy函数将表导入数据库，就有可能发生数据块错误。自建表不会。
标签：temporarily,gp,调度,连接数,实例,报错,执行,segment From： https://www.cnblogs.com/xurui96/p/17085187.html