48

将 psycopg2 包与 python 2.7 一起使用，我不断收到标题错误：psycopg2.DatabaseError: SSL SYSCALL error: EOF detected

它仅在我WHERE column LIKE ''%X%''向我的 pgrouting 查询添加子句时发生。一个例子：

SELECT id1 as node, cost FROM PGR_Driving_Distance(
  'SELECT id, source, target, cost 
     FROM edge_table
     WHERE cost IS NOT NULL and column LIKE ''%x%'' ',
  1, 10, false, false)

互联网上的线程直观地表明这是 SSL 的一个问题，但是每当我注释掉事物的模式匹配方面时，查询和与数据库的连接都可以正常工作。

这是在运行 Xubuntu 13.10 的本地数据库上。

经过进一步调查：看起来这可能是由于 pgrouting 扩展导致数据库崩溃，因为它是一个错误的查询，并且它们不是具有这种模式的链接。

很快就会发布答案...

4

8 回答 8

24

错误：psycopg2.operationalerror: SSL SYSCALL error: EOF detected

设置：气流+ Redshift + psycopg2

时间：查询需要很长时间才能执行（超过 300 秒）。

在这种情况下会发生套接字超时。解决此特定错误变体的方法是将 keepalive 参数添加到连接字符串。

keepalive_kwargs = {
    "keepalives": 1,
    "keepalives_idle": 30,
    "keepalives_interval": 5,
    "keepalives_count": 5,
}

conection = psycopg2.connect(connection_string, **keepalive_kwargs)

Redshift 要求keepalives_idle小于 300。值 30 对我有用，您的里程可能会有所不同。该keepalives_idle参数也可能是您唯一需要设置的参数 - 但确保keepalives设置为 1。

链接到 postgres keepalives 上的文档。

链接到气流文档，建议 300 timeout。

于 2020-07-28T09:16:41.677 回答
17

我在 Digital Ocean 实例上的 Droplet 中运行慢速查询时遇到了这个问题。所有其他 SQL 都可以正常运行，并且可以在我的笔记本电脑上运行。在扩展到 1 GB RAM 实例而不是 512 MB 后，它可以正常工作，因此如果进程内存不足，似乎可能会发生此错误。

于 2016-03-18T13:58:27.180 回答
9

当我运行一些恶意查询导致表被无限期锁定时，这个问题发生在我身上。我能够通过运行查看查询：

SELECT * from STV_RECENTS where status='Running' order by starttime desc;

然后杀死他们：

SELECT pg_terminate_backend(<pid>);
于 2017-12-18T19:08:30.687 回答
9

Very similar answer to what @FoxMulder900 did, except I could not get his first select to work. This works, though:

WITH long_running AS (
    SELECT pid, now() - pg_stat_activity.query_start AS duration, query, state
    FROM pg_stat_activity
    WHERE (now() - pg_stat_activity.query_start) > interval '1 minutes'
      and state = 'active'
)
SELECT * from long_running;

If you want to kill the processes from long_running just comment out the last line and insert SELECT pg_cancel_backend(long_running.pid) from long_running ;

于 2018-10-30T18:55:52.953 回答
7

在我的情况下，这是 OOM 杀手（查询太重）

检查 dmesg：

dmesg | grep -A2 Kill

就我而言：

Out of memory: Kill process 28715 (postgres) score 150 or sacrifice child
于 2019-02-01T11:24:30.540 回答
5

我遇到了同样的错误。通过 CPU，RAM 使用一切正常，@antonagestam 的解决方案对我不起作用。

基本上，问题在于创建引擎的步骤。pool_pre_ping=True解决了问题：

engine = sqlalchemy.create_engine(connection_string, pool_pre_ping=True)

它的作用是，每次使用连接时，它都会发送SELECT 1查询以检查连接。如果失败，则连接被回收并再次检查。成功后，将执行查询。

pool_pre_ping 上的 sqlalchemy 文档

就我而言，我在 python 日志中遇到了同样的错误。我检查了日志文件/var/log/postgresql/，有很多错误信息could not receive data from client: Connection reset by peer和unexpected EOF on client connection with an open transaction. 这可能是由于网络问题而发生的。

于 2021-03-07T10:51:37.927 回答
3

您可能需要表示%为%%因为%是占位符标记。http://initd.org/psycopg/docs/usage.html#passing-parameters-to-sql-queries

于 2014-08-02T23:16:23.550 回答
2

我在 300 万行表上运行大型 UPDATE 语句时遇到此错误。就我而言，事实证明磁盘已满。一旦我添加了更多空间，更新就可以正常工作。

于 2017-04-26T09:42:35.430 回答