postgresql - postgres，服务器通过VBS意外关闭了连接

Question

我得到这个错误：
“服务器意外地关闭了连接这可能意味着服务器在处理请求之前或处理请求时异常终止。”
使用此VBScript（vbs）：

dim cn
set cn = CreateObject("ADODB.Connection")  
cn.ConnectionString= "DSN=dsn_name_here" 
cn.open 
cn.CommandTimeout = 28800

cn.execute("vacuum analyze fund_data;")
cn.execute("vacuum analyze daily_data;") '<-- error here

这条线运行良好：
cn.execute("vacuum analyze fund_data;")
但这一行错误：
cn.execute("vacuum analyze daily_data;")
我想我知道为什么以及如何预防，但我想知道是否有更好的解决方案，以及如何确定根本原因。
我认为原因与缺乏资源有关。daily_data是一个比fund_data大得多的表，当这一个错误发生时，我还有另外两个相当大的查询在运行，其中一个也会因同样的错误而失败。我认为一下子发生的事情太多了，但我如何确定根本原因呢？磁盘空间不足吗？（我知道我们没有足够的内存，所以我认为查询正在写入磁盘。我们正在讨论升级我们的服务器，但我想了解并能够诊断。）有没有办法确定根目录？
我认为解决方案是以不同的方式计时查询，这样查询就不会同时运行。这里的问题是，因为我们缺乏资源，所以一切都在缓慢地进行，而且每天的日程安排已经超额预定，我需要偷偷地加入一些vacuums。有没有更好的方法从脚本的角度（或DBA的角度）而不深入实际查询的细节？
为什么postgres不减速或锁定查询，而不是终止查询？或者是别的什么不好？
PS—如果这个问题更适合DBA站点，我会把这个问题转移到DBA站点，但是我想我会先从脚本的角度来问这个问题。
编辑1：我在跑什么：
来自pgadmin：

select version();
PostgreSQL 9.6.2 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16), 64-bit

从安装PostgreSQL的虚拟服务器的终端：

lsb_release -a
LSB Version: n/a
Distributor ID: SUSE LINUX
Description: SUSE Linux Enterprise Server 12
Release: 12
Codename: 12

uname -r
3.12.28-4-default

VBScript是从Windows 7笔记本电脑上运行的。
我有什么不对劲吗？
编辑2：
我在这里更新了odbc驱动程序：
https://www.postgresql.org/ftp/odbc/versions/msi/
他们现在有了（在更新之前没有注意到我有什么）：
%WINDIR%\SysWOW64\odbcad32.exe驱动程序选项卡具有PostgreSQL ANSI（x64）9.06.05.00和PostgreSQL Unicode（x64）9.06.05.00
%WINDIR%\SysWOW64\odbcad32.exe驱动程序选项卡具有PostgreSQL ANSI 9.06.05.00和PostgreSQL Unicode 9.06.05.00
使用新的驱动程序重新启动笔记本电脑，并通过此良好但稍有不准确的链接设置到我的服务器日志文件的外部数据表：
https://dba.stackexchange.com/questions/153904/pgadmin-4-server-status-view-log-file
…所以我明天可以提供一些服务器日志。
编辑3：
除了EDIT 2之外，我重新启动了服务器。
我今天早上成功地创建了错误。和以前一样。服务器日志不显示有关vacuum查询的任何内容：

select * from postgres_log 
where query like '%vacuum%'

然而，与往常一样，vacuum和另一个同时出现“错误”的查询仍然出现在pg_stat_activity中：

select pid,query,state,wait_event,* from pg_stat_activity where state <> 'idle'

我说的“错误”是指我在最初的问题中得到了错误，但是查询似乎仍然在运行。至少吸尘器可以肯定。
最后，如果我检查我的vacuums，它将在last_vacuum下完成真空。我可以通过这个查询的日期看到这个：

 select relname,last_vacuum, last_autovacuum, last_analyze, last_autoanalyze from pg_stat_user_tables order by relname;

所以我认为服务器认为查询是好的。对我来说，这好像是剧本里的东西。vacuum现在正在运行，查询启动后没有状态更改，但此查询通常会完成。
这可能是什么？你还需要什么信息？
另外，我认为这并不重要，但在出现错误时，我正在同时运行来自VBA和VBS的查询。
编辑4：
经时间调查：

 select * from postgres_log where session_start_time > '2017-09-29 06:00:00'

我发现5个服务器日志“使用过时的统计信息而不是当前的，因为stats collector没有响应”。
注意：在出现问题的错误期间，服务器没有记录其他内容。
我很快就找到了这个错误：
https://www.postgresql.org/message-id/1457523467.24545.43.camel%402ndquadrant.com
听起来像是我的“I/O系统过载”？
编辑5：
我不确定这是否重要，但大约在这个时候，我们会遇到一些常见的LAN慢/消息传递问题。
具体地说，这是一个完全不同的进程，它使用与我原来的问题相同的局域网运行。有关详细信息：
https://serverfault.com/questions/873296/saving-large-excel-files-to-network-drive-locks-on-saving-progress-bar-popup
这有关系吗？

Answer 1

正如Eelke在评论中提到的那样，这个问题是缺乏网络可靠性。由于网络中断而中断/断开的连接（在本例中是通过vbs建立的）会导致程序（在本例中是vbscript）中出现此类错误，但不会立即产生任何服务器端错误：
“服务器意外地关闭了连接这可能意味着服务器在处理请求之前或处理请求时异常终止。”
解决方案：使网络更可靠