2009-10-15 4 views
8

He estado abordando esto por un tiempo. Configuré una máquina completamente nueva. He instalado una copia nueva de postgresql y todas mis otras dependencias. Básicamente, obtengo estas desconexiones de bases de datos en momentos aleatorios. Puedo realizar solicitudes idénticas y funciona o no. Muy no determinista en apariencia exterior. Viendo registros en Postgresql, ni siquiera obtiene una conexión. Ahora, esperaría que, si nunca se conectara, tendría este problema al establecer la conexión y obtener el cursor, pero lo entiendo cuando trato de usar la conexión más adelante. Dado el rastreo a continuación, esperaría ver una conexión en los registros de pg, y luego desconectarse por algún motivo más adelante. Yo no, así que me pregunto si hay alguna pista en esa falta de coincidencia.psycopg2 se desconecta del servidor

Traceback (most recent call last): 
    File "/usr/local/lib/python2.6/dist-packages/Django-1.1-py2.6.egg/django/core/handlers/wsgi.py", line 242, in __call__ 
    response = self.get_response(request) 
    File "/usr/local/lib/python2.6/dist-packages/Django-1.1-py2.6.egg/django/core/handlers/base.py", line 73, in get_response 
    response = middleware_method(request) 
    File "/usr/local/lib/python2.6/dist-packages/Django-1.1-py2.6.egg/django/middleware/locale.py", line 16, in process_request 
    language = translation.get_language_from_request(request) 
    File "/usr/local/lib/python2.6/dist-packages/Django-1.1-py2.6.egg/django/utils/translation/__init__.py", line 97, in get_language_from_request 
    return real_get_language_from_request(request) 
    File "/usr/local/lib/python2.6/dist-packages/Django-1.1-py2.6.egg/django/utils/translation/trans_real.py", line 349, in get_language_from_request 
    lang_code = request.session.get('django_language', None) 
    File "/usr/local/lib/python2.6/dist-packages/Django-1.1-py2.6.egg/django/contrib/sessions/backends/base.py", line 63, in get 
    return self._session.get(key, default) 
    File "/usr/local/lib/python2.6/dist-packages/Django-1.1-py2.6.egg/django/contrib/sessions/backends/base.py", line 172, in _get_session 
    self._session_cache = self.load() 
    File "/usr/local/lib/python2.6/dist-packages/Django-1.1-py2.6.egg/django/contrib/sessions/backends/db.py", line 16, in load 
    expire_date__gt=datetime.datetime.now() 
    File "/usr/local/lib/python2.6/dist-packages/Django-1.1-py2.6.egg/django/db/models/manager.py", line 120, in get 
    return self.get_query_set().get(*args, **kwargs) 
    File "/usr/local/lib/python2.6/dist-packages/Django-1.1-py2.6.egg/django/db/models/query.py", line 300, in get 
    num = len(clone) 
    File "/usr/local/lib/python2.6/dist-packages/Django-1.1-py2.6.egg/django/db/models/query.py", line 81, in __len__ 
    self._result_cache = list(self.iterator()) 
    File "/usr/local/lib/python2.6/dist-packages/Django-1.1-py2.6.egg/django/db/models/query.py", line 238, in iterator 
    for row in self.query.results_iter(): 
    File "/usr/local/lib/python2.6/dist-packages/Django-1.1-py2.6.egg/django/db/models/sql/query.py", line 287, in results_iter 
    for rows in self.execute_sql(MULTI): 
    File "/usr/local/lib/python2.6/dist-packages/Django-1.1-py2.6.egg/django/db/models/sql/query.py", line 2369, in execute_sql 
    cursor.execute(sql, params) 
    File "/usr/local/lib/python2.6/dist-packages/Django-1.1-py2.6.egg/django/db/backends/util.py", line 19, in execute 
    return self.cursor.execute(sql, params) 
OperationalError: server closed the connection unexpectedly 
     This probably means the server terminated abnormally 
     before or while processing the request. 
+0

creo que una solución parcial para el problema podría encontrarse aquí: http://stackoverflow.com/a/33128806/2144966 – Kalle

Respuesta

4

Esta es una pregunta muy similar a la publicada aquí:

Django + FastCGI - randomly raising OperationalError

Imagino que la respuesta será la misma tanto si y cuando alguien finalmente lo descubrió. Este mismo problema me ha estado molestando por aproximadamente un mes y no tengo idea de qué podría estar causando esto.

+0

Finalmente me señalaron eso el día de hoy y estaba planeando unirme a él desde aquí. Este es un problema real, y obviamente muchos de nosotros nos hemos topado con él, pero puede ser muy difícil tomar la evidencia y encontrar información. Gracias por el consejo. – ironfroggy

2

¿Te fork() procesos secundarios (utilización preforked FastCGI o algo similar)? Esta podría ser la razón por la que la conexión establecida en el proceso principal no funciona en el niño. Si usa el método prefabricado, es fácil pasar al subprocesamiento para ver si el problema se ha solucionado. Vi exactamente el mismo error flotante en tal caso.

+0

Mientras estoy usando un backend FastCgi preformado, la conexión se establece por solicitud, en los procesos hijos. Además, si algo como esto fuera el caso, esperaría que el problema fuera más predecible, mientras que en realidad las solicitudes suelen tener éxito y la falla es externamente no determinista. – ironfroggy

+0

Cuando el error secundario hereda el descriptor de socket y le envía datos, cualquier niño (este u otro) puede recibir una respuesta. Eso causa que el error sea flotante. Sugiero agregar el registro para asegurar que la conexión se inicialice después del tenedor. Debido al uso extensivo de variables globales en django, el establecimiento de la conexión temprana puede ocultarse a simple vista. Tenga en cuenta que todo el código se importó antes de la bifurcación. –

+0

Ya he iniciado sesión para determinar esto. La conexión solo se realiza a la hora de solicitud, en el niño, en respuesta a la señal de solicitud de inicio. Los procesos secundarios ya están establecidos antes de que se envíe esa solicitud para activar la conexión. – ironfroggy

2

Aunque es una pregunta muy antigua, La mejor solución que he encontrado está en this answer. simplemente haga lo siguiente:

from django import db 

y antes de llamar usando un tenedor o multiprocesamiento ejecutar:

db.connections.close_all() 
Cuestiones relacionadas