views:

57

answers:

1

I'm running a Django project on Postgresql 8.1.21 (using Django 1.1.1, Python2.5, psycopg2, Apache2 with mod_wsgi 3.2). We've recently encountered this lovely error:

OperationalError: FATAL: connection limit exceeded for non-superusers

I'm not the first person to run up against this. There's a lot of discussion about this error, specifically with psycopg, but much of it centers on older versions of Django and/or offer solutions involving edits to code in Django itself. I've yet to find a succinct explanation of how to solve the problem of the Django ORM (or psycopg, whichever is really responsible, in this case) leaving open Postgre connections.

Will simply adding connection.close() at the end of every view solve this problem? Better yet, has anyone conclusively solved this problem and kicked this error's ass?

Edit: we later upped Postgresql's limit to 500 connections; this prevented the error from cropping up, but replaced it with excessive memory usage.

+1  A: 

This could be caused by other things. For example, configuring Apache/mod_wsgi in a way that theoretically it could accept more concurrent requests than what the database itself may be able to accept at the same time. Have you reviewed your Apache/mod_wsgi configuration and compared limit on maximum clients to that of PostgreSQL to make sure something like that hasn't been done. Obviously this presumes though that you have managed to reach that limit in Apache some how and also depends on how any database connection pooling is set up.

Graham Dumpleton
I'll sound obtuse, but are you referring to WSGIDaemonProcess's maximum-requests setting, or Apache's MaxClient?
bennylope
It really depends on whether you are using embedded mode or daemon mode of mod_wsgi. I cant guess what you are running so had to generalise.
Graham Dumpleton
Thanks, that makes sense. I've noticed that the database (ORM/psycopg) is still leaving connections open even after setting the DB's connection limit above the MaxClients limit (running in embedded mode for now). It definitely good to know; I think in this instance the error is still resulting in the ORM(?) not closing these connections.
bennylope