通过 ssh 隧道的 SELECT 查询中结果集的大小限制 - postgresql答案

【问题标题】：Size limit for result set in SELECT query via ssh tunnel - postgresql通过 ssh 隧道的 SELECT 查询中结果集的大小限制 - postgresql
【发布时间】：2012-01-31 23:11:48
【问题描述】：

我在通过 ssh 隧道连接执行 SELECT 查询和接收大型（> 550 MB 数据）结果集时遇到问题。 SELECT 查询在本地工作，即在 PostgreSQL 服务器所在的同一台服务器上。

错误消息是，在客户端：

server closed the connection unexpectedly
    This probably means the server terminated abnormally
    before or while processing the request.
connection to server was lost

服务器端的错误消息（postgresql.log）

08006: could not receive data from client: Connection reset by peer

当我让服务器日志变得更详细时，其中出现了很多，但我猜它们与手头的问题无关：

LOG:  08P01: SSL error: unsafe legacy renegotiation disabled

我没有找到任何 postgres 选项或类似的选项来控制“远程结果集最大大小”。

错误发生前使用的最大内存约为 519 MB（来自 /proc/PID/status 的 VmData），然后查询运行了 1 分 55 秒。 postgres conf 文件中没有设置 statement_timeout。

出于手头的目的，我必须一次将所有数据都保存在内存中，因此不能选择光标或其他东西。

Postgres 服务器版本 8.3

【问题讨论】：

标签： postgresql ssl

【解决方案1】：

看起来 SSL 重新协商 是您问题的根源。默认设置是每 512MB 重新协商一次 - 这与您的描述非常接近。

特别是，一些older SSL 库无法进行 SSL 重新协商 - 以防止协议中的（旧）错误。

尝试在您的postgresql.conf 中禁用ssl_renegotiation_limit。

ssl_renegotiation_limit = 0

More about that in the manual（链接到版本 8.3）。

【讨论】：

确实是重点！然而，为了提高稳健性，我选择使用限制/偏移量以及关闭和打开数据库连接来加载多组数据。谢谢！
@EwaldKeinNachname：多个连接并不是绝对必要的。一旦 SSL 重新协商成功，512 MB 就完全没有问题了。我假设您知道中间对表的写操作可能会弄乱过程？如果您关心健壮性，您可能需要更新您的系统（SSL 库）和您的 PostgreSQL 版本。两者都相当老了。