wake-up-neo.com

Postgres SSL SYSCALL Fehler: EOF mit Python und Psycopg nachgewiesen

Bei Verwendung des Pakets psycopg2 mit python 2.7 erhalte ich weiterhin den Titelfehler: psycopg2.DatabaseError: SSL-SYSCALL-Fehler: EOF erkannt

Es tritt nur auf, wenn ich meiner pgrouting-Abfrage eine WHERE column LIKE ''%X%''-Klausel hinzufüge. Ein Beispiel:

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)

Threads im Internet legen nahe, dass es sich um ein intuitives Problem mit SSL handelt. Wenn ich jedoch die Seite mit den Mustersuchläufen auskommentiere, funktioniert die Abfrage und Verbindung zur Datenbank einwandfrei.

Dies ist in einer lokalen Datenbank, auf der Xubuntu 13.10 ausgeführt wird.

Nach weiteren Untersuchungen: Es sieht so aus, als könnte dies daran liegen, dass die Erweiterung pgrouting die Datenbank abstürzt, da es sich um eine fehlerhafte Abfrage handelt und es sich nicht um Links handelt, die dieses Muster aufweisen.

Wird bald eine Antwort posten ...

21
Phil Donovan

Dieses Problem trat auf, wenn eine langsame Abfrage in einem Droplet in einer Digital Ocean-Instanz ausgeführt wurde. Alle anderen SQL-Programme liefen gut und es funktionierte auf meinem Laptop. Nach der Skalierung auf eine Instanz von 1 GB RAM anstelle von 512 MB funktioniert dies einwandfrei. Es kann also sein, dass dieser Fehler auftreten kann, wenn der Prozess nicht mehr ausreicht.

10
antonagestam

Dieses Problem trat bei mir auf, als einige unerwünschte Abfragen ausgeführt wurden, die dazu führten, dass Tabellen auf unbestimmte Zeit gesperrt wurden. Ich konnte die Abfragen durch Ausführen von sehen:

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

dann töte sie mit:

SELECT pg_terminate_backend(<pid>);
5
FoxMulder900

Möglicherweise müssen Sie % als %% ausdrücken, da % die Platzhalter-Markierung ist. http://initd.org/psycopg/docs/usage.html#passing-parameters-to-sql-queries

2
piro

Sehr ähnliche Antwort auf das, was @ FoxMulder900 getan hat, außer dass ich seine erste Auswahl nicht zur Arbeit bekommen konnte. Das funktioniert aber:

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;

Wenn Sie die Prozesse von long_running beenden möchten, kommentieren Sie einfach die letzte Zeile aus und fügen Sie SELECT pg_cancel_backend(long_running.pid) from long_running ; ein.

1
Charles F

Ich habe diesen Fehler bei der Ausführung einer großen UPDATE-Anweisung für eine 3 Millionen-Zeilentabelle erhalten. In meinem Fall stellte sich heraus, dass die Festplatte voll war. Nachdem ich mehr Speicherplatz hinzugefügt hatte, funktionierte das UPDATE einwandfrei.

1
Fiskabollen

In meinem Fall war das OOM-Killer (Abfrage ist zu schwer)

Überprüfen Sie dmesg:

dmesg | grep -A2 Kill

In meinem Fall:

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