Edgewall Software

Opened 12 years ago

Closed 12 years ago

Last modified 7 years ago

#9623 closed defect (fixed)

PostgreSQL authentication error throws cryptic exception

Reported by: gabrtv Owned by: Christian Boos
Priority: normal Milestone: 0.12.1
Component: database backend Version: 0.12-stable
Severity: normal Keywords: error, postgresql, database, apache, modpython
Cc: Jonas Borgström Branch:
Release Notes:
API Changes:
Internal Changes:


After issuing a GET to /trac, Apache/mod-python return the following cryptic error message:

Traceback (most recent call last):
  File "/usr/local/lib/python2.6/dist-packages/Trac-0.12.1dev_r10109-py2.6.egg/trac/web/api.py", line 436, in send_error
    data, 'text/html')
  File "/usr/local/lib/python2.6/dist-packages/Trac-0.12.1dev_r10109-py2.6.egg/trac/web/chrome.py", line 803, in render_template
    message = req.session.pop('chrome.%s.%d' % (type_, i))
  File "/usr/local/lib/python2.6/dist-packages/Trac-0.12.1dev_r10109-py2.6.egg/trac/web/api.py", line 212, in __getattr__
    value = self.callbacks[name](self)
  File "/usr/local/lib/python2.6/dist-packages/Trac-0.12.1dev_r10109-py2.6.egg/trac/web/main.py", line 300, in _get_session
    return Session(self.env, req)
  File "/usr/local/lib/python2.6/dist-packages/Trac-0.12.1dev_r10109-py2.6.egg/trac/web/session.py", line 166, in __init__
  File "/usr/local/lib/python2.6/dist-packages/Trac-0.12.1dev_r10109-py2.6.egg/trac/web/session.py", line 225, in promote_session
  File "/usr/local/lib/python2.6/dist-packages/Trac-0.12.1dev_r10109-py2.6.egg/trac/db/api.py", line 82, in transaction_wrapper
  File "/usr/local/lib/python2.6/dist-packages/Trac-0.12.1dev_r10109-py2.6.egg/trac/db/util.py", line 102, in __getattr__
    return getattr(self.cnx, name)
AttributeError: 'tuple' object has no attribute 'rollback'

The error should probably be a bit more descriptive. Environment is Ubuntu 10.04 x64 with a generic trac 0.12 install.

Attachments (1)

9623-active.patch (1.9 KB ) - added by Christian Boos 12 years ago.
more robust deferred operations when taking a connection from the pool.

Download all attachments as: .zip

Change History (10)

comment:1 by osimons, 12 years ago

I just looked at this briefly when it appeard on IRC, and according to user the error was a Postgres authentication error - which is then a typical database error that can occur for various reasons. Some assumption inside transaction_wrapper does not hold in such circumstances.

comment:2 by Christian Boos, 12 years ago

I wonder if we still have a similar error with 0.12-stable, as the pool code has changed quite a bit. Would someone mind testing? (or I'll test it myself on some innocent 0.12-stable instance, like … Bitten! :-) ).

comment:3 by Christian Boos, 12 years ago

Milestone: 0.12.1
Owner: set to Christian Boos
Status: newassigned

This can actually happen as a secondary error, if a database connection couldn't be created (the ('create', None) entry is kept in the _active dict). I have already fixed that in the forthcoming changes in the db layer for 0.13dev, need to backport this specific fix.

comment:4 by Christian Boos, 12 years ago

Specifically this hunk:

  • trac/db/pool.py

    a b  
    11398            elif op == 'close':
    11499                cnx.close()
    115100            if op in ('close', 'create'):
    116                 cnx = connector.get_connection(**kwargs)
     101                try:
     102                    cnx = connector.get_connection(**kwargs)
     103                except Exception: # couldn't create a new connection
     104                    with self._available:
     105                        del self._active[(tid, key)]
     106                    raise

by Christian Boos, 12 years ago

Attachment: 9623-active.patch added

more robust deferred operations when taking a connection from the pool.

comment:5 by Christian Boos, 12 years ago

Ok, I backported and refined the patch above. Please test 9623-active.patch. I think it's a safe fix but more review can't hurt, especially that close to release ;-)

comment:6 by Remy Blank, 12 years ago

The patch works fine here on Linux, OS X and Windows 7. But I have to admit that you have lost me long ago with the logic in the DB pool…

in reply to:  6 comment:7 by Christian Boos, 12 years ago

Cc: Jonas Borgström added
Component: generaldatabase backend

Replying to rblank:

The patch works fine here on Linux, OS X and Windows 7.

Thanks for testing! Ideally, we should also test what's happening when Trac is running fine with PostgreSQL or MySQL and the DB is suddenly shut down…

But I have to admit that you have lost me long ago with the logic in the DB pool…

Well, the story goes like that:

  • jonas produces a simple, nice and clean pool mechanism
  • some corner cases appear
  • cboos tries to handle them all and makes the whole thing overly complex…

Repeat. So let's wait for the next iteration from jonas ;-)

comment:8 by Christian Boos, 12 years ago

Resolution: fixed
Status: assignedclosed

Ok, as I was surprised to get again a TimeoutError when testing the patch, I realized this was because the database I attempted to connect to was no longer existing. So the 'create' deferred step failed, but we didn't show why.

I added that to the error message (appended, because of the string freeze), in addition to the previous changes from 9623-active.patch.

Fix committed in r10151.

comment:9 by Ryan J Ollos, 7 years ago

Keywords: postgres removed

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain Christian Boos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Christian Boos to the specified user.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.