Ticket #3394 (closed defect: fixed)
Opened 6 years ago
Last modified 6 years ago
trac fails to use cached postgresql connection
| Reported by: | flfr@… | Owned by: | cmlenz |
|---|---|---|---|
| Priority: | normal | Milestone: | 0.10 |
| Component: | web frontend/mod_python | Version: | 0.9.6 |
| Severity: | major | Keywords: | postgresql connection timeout |
| Cc: | |||
| Release Notes: | |||
| API Changes: | |||
Description (last modified by cmlenz) (diff)
One morning I came into work to find trac making these noises in stead of working, we're using Trac 0.9.6 on top of postgresql, after restarting apache, trac returned to its normal self.
I've checked with the postgresql docs and pg doesn't have connection timeouts.
The problem is reproducible by:
- Starting apache and requesting a couple of trac pages.
- Restarting pg
- Requesting another trac page.
The problem seems to be slightly related to #2437.
I have not looked at the code yet, but all other connection pooling systems I've seen start by testing the connection if it was pulled from the cache, this test is obviously missing or broken in trac.
Oops...
Trac detected an internal error:
FATAL: terminating connection due to administrator command
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
Traceback (most recent call last):
File "/usr/local/lib/python2.4/site-packages/trac/web/modpython_frontend.py", line 206, in handler
dispatch_request(mpr.path_info, mpr, env)
File "/usr/local/lib/python2.4/site-packages/trac/web/main.py", line 139, in dispatch_request
dispatcher.dispatch(req)
File "/usr/local/lib/python2.4/site-packages/trac/web/main.py", line 80, in dispatch
req.perm = PermissionCache(self.env, req.authname)
File "/usr/local/lib/python2.4/site-packages/trac/perm.py", line 276, in __init__
self.perms = PermissionSystem(env).get_user_permissions(username)
File "/usr/local/lib/python2.4/site-packages/trac/perm.py", line 132, in get_user_permissions
for perm in self.store.get_user_permissions(username):
File "/usr/local/lib/python2.4/site-packages/trac/perm.py", line 212, in get_user_permissions
cursor = db.cursor()
File "/usr/local/lib/python2.4/site-packages/trac/db.py", line 106, in cursor
return IterableCursor(self.cnx.cursor())
File "/usr/local/lib/python2.4/site-packages/trac/db.py", line 106, in cursor
return IterableCursor(self.cnx.cursor())
File "/usr/local/lib/python2.4/site-packages/pyPgSQL/PgSQL.py", line 2599, in cursor
return Cursor(self, name, isRefCursor)
File "/usr/local/lib/python2.4/site-packages/pyPgSQL/PgSQL.py", line 2718, in __init__
self.conn._Connection__setupTransaction()
File "/usr/local/lib/python2.4/site-packages/pyPgSQL/PgSQL.py", line 2510, in __setupTransaction
self.conn.query("BEGIN WORK")
OperationalError: FATAL: terminating connection due to administrator command
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
Attachments
Change History
comment:1 Changed 6 years ago by flfr@…
comment:2 Changed 6 years ago by cmlenz
- Description modified (diff)
- Milestone set to 0.10
- Status changed from new to assigned
Thanks for the patch!
comment:3 Changed 6 years ago by cmlenz
- Resolution set to fixed
- Status changed from assigned to closed
Committed in [3530].



Sorry it took so long, but I've finally fixed the problem, in db.py, line 155 where it says:
if self._dormant: cnx = self._dormant.pop() breakReplace the line:
With this code:
try: cnx.cursor() break except Exception: cnx.close()The cnx.cursor() throws an exception if the connection has gone stale, a dedicated cnx.ping() function would be nicer, though.
I've only tested this with postgresql, but I see no reason it shouldn't work with any other backend as well.