Postgres SSL SYSCALL error: EOF detectado con python y psycopg
postgresql psycopg2 (5)
Usando el paquete psycopg2 con python 2.7 Sigo recibiendo el error titulado: psycopg2.DatabaseError: SSL SYSCALL error: EOF detectado
Solo ocurre cuando agrego una cláusula WHERE column LIKE ''''%X%''''
a mi consulta de publicación. Un ejemplo:
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)
Los hilos en Internet sugieren que es un problema con SSL de forma intuitiva, pero cada vez que comento el lado de la coincidencia de patrones, la consulta y la conexión a la base de datos funcionan bien.
Esto está en una base de datos local que ejecuta Xubuntu 13.10.
Después de una investigación adicional: parece que esto puede deberse a que la extensión pgrouting bloquee la base de datos porque es una consulta incorrecta y no son enlaces que tengan este patrón.
Publicaré una respuesta pronto ...
Es posible que deba expresar %
como %%
porque %
es el marcador de posición. http://initd.org/psycopg/docs/usage.html#passing-parameters-to-sql-queries
Este problema se produjo cuando tuve algunas consultas falsas en ejecución, lo que provocó el bloqueo indefinido de las tablas. Pude ver las consultas ejecutando:
SELECT * from STV_RECENTS where status=''Running'' order by starttime desc;
entonces matalos con:
SELECT pg_terminate_backend(<pid>);
Me encontré con este problema al ejecutar una consulta lenta en un Droplet en una instancia de Digital Ocean. El resto de SQL funcionaría bien y funcionó en mi computadora portátil. Después de escalar hasta una instancia de 1 GB de RAM en lugar de 512 MB, funciona bien, por lo que parece que este error podría ocurrir si el proceso se está quedando sin memoria.
Recibí este error al ejecutar una gran instrucción UPDATE en una tabla de 3 millones de filas. En mi caso resultó que el disco estaba lleno. Una vez que agregué más espacio, la ACTUALIZACIÓN funcionó bien.
Respuesta muy similar a lo que hizo @ FoxMulder900, excepto que no pude hacer que su primera selección funcionara. Esto funciona, sin embargo:
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;
Si desea eliminar los procesos de long_running
comente la última línea e inserte SELECT pg_cancel_backend(long_running.pid) from long_running ;