Ich habe mich schon eine Weile damit beschäftigt. Ich habe eine komplett neue Maschine eingerichtet. Ich habe eine neue Kopie von Postgresql und all meinen anderen Abhängigkeiten installiert. Grundsätzlich bekomme ich diese Datenbankunterbrechungen zu zufälligen Zeiten. Ich kann identische Anfragen ausführen und entweder funktioniert es oder nicht. Sehr nichtdeterministisch in der äußeren Erscheinung. Wenn man sich PostgreSQL anschaut, bekommt es nicht einmal eine Verbindung. Nun würde ich erwarten, dass wenn ich nie eine Verbindung herstellen würde, ich dieses Problem bekommen würde, wenn ich die Verbindung herstelle und den Cursor bekomme, aber ich bekomme es, wenn ich versuche, die Verbindung später zu benutzen. Angesichts der folgenden Rückverfolgung würde ich erwarten, dass in den PG-Protokollen eine Verbindung hergestellt wird, die später aus irgendeinem Grund getrennt wird. Ich weiß es nicht, also frage ich mich, ob es einen Anhaltspunkt dafür gibt.
%Vor%Dies ist eine sehr ähnliche Frage zu der hier geposteten:
Django + FastCGI - zufälliges Anheben von OperationalError
Ich kann mir vorstellen, dass die Antwort für beide gleich ist, ob und wann jemand es herausgefunden hat. Das gleiche Problem beschäftigt mich seit ungefähr einem Monat und ich habe keine Ahnung, was es verursachen könnte.
Haben Sie fork() untergeordnete Prozesse (verwenden Sie vorgekochte FastCGI oder ähnliches)? Dies könnte der Grund dafür sein, dass die Verbindung, die im Elternprozess hergestellt wurde, nicht in Child funktioniert. Wenn Sie die Methode preforked verwenden, können Sie ganz einfach zum Threading wechseln, um zu sehen, ob das Problem behoben wurde. In diesem Fall habe ich genau den gleichen Gleitfehler gesehen.
Obwohl es eine sehr alte Frage ist, Die beste Lösung, die ich gefunden habe, ist diese Antwort. mach einfach folgendes:
%Vor%und vor dem Aufruf von fork oder Multiprocessing ausführen:
%Vor%Tags und Links python django database postgresql psycopg2