web-dev-qa-db-fra.com

Erreur PostgreSQL SYSCALL: EOF détecté avec python et psycopg

Utilisation du package psycopg2 avec python 2.7, l'erreur continue à apparaître: psycopg2.DatabaseError: erreur SSL SYSCALL: EOF détectée

Cela ne se produit que lorsque j'ajoute une clause WHERE column LIKE ''%X%'' à ma requête de routage. Un exemple:

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)

Les discussions sur Internet suggèrent que SSL est un problème intuitivement, mais chaque fois que je commente le type de correspondance des motifs, la requête et la connexion à la base de données fonctionnent correctement.

Ceci est sur une base de données locale exécutant Xubuntu 13.10.

Après une enquête plus approfondie: Il semble que cela puisse être causé par l’arrêt de la sauvegarde de la base de données par l’extension pgrouting car il s’agit d’une requête incorrecte et que ce ne sont pas des liens comportant ce modèle.

Publierai une réponse bientôt ...

pythonpostgresqlsslpsycopg2pgrouting
21
Phil Donovan

J'ai rencontré ce problème lors de l'exécution d'une requête lente dans un droplet sur une instance de Digital Ocean. Tous les autres SQL fonctionneraient bien et cela fonctionnait sur mon ordinateur portable. Après la mise à l'échelle d'une instance RAM de 1 Go au lieu de 512 Mo, cela fonctionne correctement. Cette erreur peut donc se produire si le processus manque de mémoire.

10
antonagestam

Ce problème s'est produit lorsque des requêtes non autorisées ont été exécutées, provoquant le verrouillage indéfini des tables. J'ai pu voir les requêtes en exécutant:

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

puis tuez-les avec:

SELECT pg_terminate_backend(<pid>);
5
FoxMulder900

Vous devrez peut-être exprimer % sous la forme %% car % est le marqueur d'espace réservé. http://initd.org/psycopg/docs/usage.html#passing-parameters-to-sql-queries

2
piro

Réponse très similaire à ce que @ FoxMulder900 a fait, sauf que je n'ai pas pu obtenir son premier choix au travail. Cela fonctionne, cependant:

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 vous souhaitez supprimer les processus de long_running, mettez en commentaire la dernière ligne et insérez SELECT pg_cancel_backend(long_running.pid) from long_running ;.

1
Charles F

J'ai eu cette erreur en exécutant une grande instruction UPDATE sur une table de 3 millions de lignes. Dans mon cas, le disque était plein. Une fois que j'ai ajouté plus d'espace, l'UPDATE a bien fonctionné.

1
Fiskabollen

Dans mon cas, c’était le tueur OOM (la requête est trop lourde)

Vérifiez dmesg:

dmesg | grep -A2 Kill

Dans mon cas:

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