2009-10-15 16 views
8

L'ho affrontato per un po '. Ho installato una macchina completamente nuova. Ho installato una nuova copia di postgresql e tutte le altre mie dipendenze. Fondamentalmente, ottengo queste disconnessioni del database in momenti casuali. Posso eseguire richieste identiche e funziona o no. Molto non deterministico nell'aspetto esteriore. Guardando i registri su Postgresql, non ottiene nemmeno una connessione. Ora, mi sarei aspettato che se non fosse mai connesso avrei avuto questo problema quando ho stabilito la connessione e ottenuto il cursore, ma ho capito quando ho provato a utilizzare la connessione in un secondo momento. Dato il traceback qui sotto, mi aspetterei di vedere una connessione fatta nei log di pg e quindi disconnesso per qualche motivo in seguito. Non lo so, quindi mi chiedo se ci sia qualche indizio in quella mancata corrispondenza.psycopg2 si disconnette dal server

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

Penso una soluzione parziale per il vostro problema potrebbe essere trovato qui: http://stackoverflow.com/a/33128806/2144966 – Kalle

risposta

4

Questa è una domanda molto simile a quello postato qui:

Django + FastCGI - randomly raising OperationalError

Immagino che la risposta sarà la stessa per entrambi se e quando qualcuno finalmente capito. Questo stesso problema mi ha infastidito per circa un mese e non ho idea di cosa potrebbe causarlo.

+0

Finalmente me lo sono fatto notare prima e stavo progettando di collegarlo da solo. Questo è un problema reale, e ovviamente molti di noi lo hanno incontrato, ma può essere molto difficile prendere le prove e trovare informazioni. Grazie per il consiglio. – ironfroggy

2

Ti fork() processi figli (uso prefork FastCGI o qualcosa di simile)? Questo potrebbe essere il motivo per cui la connessione stabilita nel processo genitore non funziona nel bambino. Se si utilizza il metodo di preforking è facile passare al threading per vedere se il problema è andato via. Ho visto esattamente lo stesso errore fluttuante in questo caso.

+0

Mentre utilizzo un backend veloce precaricato, la connessione viene stabilita per richiesta, nei processi figli. Inoltre, se qualcosa del genere fosse il caso mi aspetterei che il problema fosse più prevedibile, mentre in realtà le richieste di solito riescono e il fallimento è esternamente non deterministico. – ironfroggy

+0

Quando l'errore figlio eredita il descrittore di socket e invia i dati ad esso, qualsiasi bambino (questo o altri) può ricevere risposta. Questo fa sì che l'errore sia mobile. Suggerisco di aggiungere la registrazione per assicurare che la connessione sia inizializzata dopo la forcella. A causa dell'uso estensivo di variabili globali nel django, la connessione iniziale può essere nascosta ai tuoi occhi. Nota, l'intero codice in importato prima del fork. –

+0

Ho già effettuato il login per determinarlo. La connessione viene effettuata solo al momento della richiesta, nel bambino, in risposta al segnale di richiesta di avvio. I processi figli sono già stati stabiliti prima di essere inviati a tale richiesta per attivare la connessione. – ironfroggy

2

Anche se è una domanda molto vecchia, La migliore soluzione che ho trovato è la risposta this. basta effettuare le seguenti operazioni:

from django import db 

e prima di chiamare forchetta o con multiprocessing eseguire:

db.connections.close_all()