我们正在尝试将所有数据库数据移动到其他位置。我们选择执行 pg_dump 并且遇到了一些问题：
首先是内存不足问题：在 pg_dump 初始化期间我们得到一个错误：
pg_dump: saving search_path =
pg_dump: saving database definition
out of memory
然后我们给 VM +16GB 的 RAM，所以总共 24GB，pg_dump 进程通过了它，现在我们有另一个问题：
pg_dump: dumping contents of table lob_messages
Write failed: Connection reset by peer
gumul@IT-dep:~$
到目前为止，错误只发生在这个“lob_messages”表上，这个表很大——pgAdmin 显示 256GB 大小。我已经尝试过 pg_dump 所有数据库，在那个错误之后我只在那个确切的表上尝试过 pg_dump。错误仍然发生。
我们正在使用 Postgesql 9,4。我们的系统管理员不知道这个问题。这是 htop 视图：
这是 df -h 视图：
我试图在 /mnt 挂载的 NAS 存储上以及本地 /var/lib/postgresql/9.4/main 中制作 pg_dump 文件
这是 postgresql.conf 更改的设置：
错误仍然存在。你能分享一些我做错的智慧吗？在那个错误期间（连接被对等重置）我从服务器断开连接，但只在运行 pg_dump 的那个会话上。在该错误期间，在其他连接（监控 htop）上保持连接。
这看起来像是错误来自您的 ssh 会话，而不是 pg_dump。使用 'screen' 或 'tmux' 以便您可以在 ssh 失败后恢复会话。
也许 pg_dump 仍在运行，或者正常完成，即使它的控制会话消失了。
是的。主要问题出在防火墙配置中。之后有一个会话限制（两个小时），所有“空闲”会话都被丢弃。
从防火墙的角度来看，htop 不会进入“空闲”状态，而 pg_dump 会。