Ошибка Postgres SSL SYSCALL: обнаружен EOF с помощью python и psycopg

Использование пакета psycopg2 с python 2.7 Я продолжаю получать титульную ошибку: psycopg2.DatabaseError: ошибка SSL SYSCALL: обнаружена EOF

Это происходит только тогда, когда я добавляю предложение 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, сбой базы данных, потому что это плохой запрос, и они не являются ссылками, которые имеют этот шаблон.

Скоро опубликует ответ...

Ответ 1

Я столкнулся с этой проблемой при запуске медленного запроса в капелле в экземпляре Digital Ocean. Все остальные SQL будут работать нормально, и это работает на моем ноутбуке. После масштабирования до экземпляра RAM объемом 1 ГБ вместо 512 МБ он работает нормально, поэтому кажется, что эта ошибка может возникнуть, если процесс заканчивается из памяти.

Ответ 2

Эта проблема возникла для меня, когда у меня возникли некоторые изгоняющие запросы, вызывающие блокировку таблиц на неопределенный срок. Я смог просмотреть запросы, выполнив:

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

затем уничтожьте их:

SELECT pg_terminate_backend(<pid>);

Ответ 3

Вам может потребоваться выразить % как %%, потому что % является маркером-заполнителем. http://initd.org/psycopg/docs/usage.html#passing-parameters-to-sql-queries

Ответ 4

У меня возникла ошибка при выполнении большого оператора UPDATE в таблице из 3 миллионов строк. В моем случае оказалось, что диск был заполнен. Когда я добавил больше места, UPDATE работал нормально.

Ответ 5

Очень похожий ответ на то, что сделал @FoxMulder900, за исключением того, что я не мог заставить его первый выбор работать. Это работает, хотя:

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;

Если вы хотите убить процессы из long_running просто закомментируйте последнюю строку и вставьте SELECT pg_cancel_backend(long_running.pid) from long_running ;

Ответ 6

В моем случае это был убийца OOM (запрос слишком тяжелый)

Проверьте dmesg:

dmesg | grep -A2 Kill

В моем случае:

Out of memory: Kill process 28715 (postgres) score 150 or sacrifice child