Error getting user's permissions with Postgres

[anonymous]

​http://trac.gajim.org/ticket/2468 Oops… Trac detected an internal error:

If you think this really should work and you can reproduce it, you should consider reporting this problem to the Trac team.

Go to ​http://trac.edgewall.org/ and create a new ticket where you describe the problem, how to reproduce it. Don't forget to include the Python traceback found below.

TracGuide — The Trac User and Administration Guide Python Traceback

Traceback (most recent call last):
  File "/var/lib/python-support/python2.4/trac/web/main.py", line 387, in dispatch_request
    dispatcher.dispatch(req)
  File "/var/lib/python-support/python2.4/trac/web/main.py", line 183, in dispatch
    req.perm = PermissionCache(self.env, req.authname)
  File "/var/lib/python-support/python2.4/trac/perm.py", line 263, in __init__
    self.perms = PermissionSystem(env).get_user_permissions(username)
  File "/var/lib/python-support/python2.4/trac/perm.py", line 227, in get_user_permissions
    for perm in self.store.get_user_permissions(username):
  File "/var/lib/python-support/python2.4/trac/perm.py", line 112, in get_user_permissions
    rows = cursor.fetchall()
  File "/usr/lib/python2.4/site-packages/pyPgSQL/PgSQL.py", line 3261, in fetchall
    return self.__fetchManyRows(self._rows_, _list)
  File "/usr/lib/python2.4/site-packages/pyPgSQL/PgSQL.py", line 2838, in __fetchManyRows
    _j = self.__fetchOneRow()
  File "/usr/lib/python2.4/site-packages/pyPgSQL/PgSQL.py", line 2813, in __fetchOneRow
    _j.append(_c.typecast(self.description[_i],
TypeError: unsubscriptable object

[Matthew Good]

Are you the administrator of the Gajim site? If you're not the administrator please report it to their admin because they will need to provide more information to help in resolving this.

Based on the traceback this looks like it's likely to be a bug in pyPgSQL, so I'd recommend checking the version of pyPgSQL in use and upgrade it if possible.

[sid]

Closing due to lack of information. Most likely a pyPgSQL bug.

[hvram1 AT gmail.com]

I get the same error and the same trace This is the sequence of steps that I have done :

I have Trac set up and running for about 8 months. Trac authenticates using the LDAP Server . things were fine and there was no error. Recently there was a requirement for access control. I applied the RBAC patch as described in ticket ​Ticket 898 Since I could not create groups in LDAP ( I am using the Zimbra LDAP server and there did not seem to be any easy way to create groups ) I created a set of groups in the auth.ini file

I also noticed that I had to create groups in the Web Admin tool in the wiki since this grouping in the ini file did not reflect in the UI . So I created a new group and also deleted the anonymous group / permissions .

I checked the version of PyPgsql and I seem to have the latest version. (2.5.1) .

2007-09-27 10:37:11,469 Trac[main] ERROR: unsubscriptable object Traceback (most recent call last):

File "/usr/lib/python2.4/site-pacages/trac/web/main.py", line 387, in dispatch_request dispatcher.dispatch(req) File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 183, in dispatch req.perm = PermissionCache(self.env, req.authname) File "/usr/lib/python2.4/site-packages/trac/perm.py", line 263, in init self.perms = PermissionSystem(env).get_user_permissions(username) File "/usr/lib/python2.4/site-packages/trac/perm.py", line 227, in get_user_permissions for perm in self.store.get_user_permissions(username): File "/usr/lib/python2.4/site-packages/trac/perm.py", line 112, in get_user_permissions rows = cursor.fetchall() File "/usr/lib/python2.4/site-packages/pyPgSQL/PgSQL.py", line 3261, in fetchall

return self.fetchManyRows(self._rows_, _list)

File "/usr/lib/python2.4/site-packages/pyPgSQL/PgSQL.py", line 2838, in fetchManyRows

_j = self.fetchOneRow()

File "/usr/lib/python2.4/site-packages/pyPgSQL/PgSQL.py", line 2813, in fetchOneRow

_j.append(_c.typecast(self.description[_i],

TypeError: unsubscriptable object

[Christian Boos]

#6236 reported a similar problem with fetchone on an empty result set.

[Dave Abrahams <dave@…>]

Replying to cboos:

#6236 reported a similar problem with fetchone on an empty result set.

Correction: the result set wasn't empty. It had one row. The cursor was getting its "res" attribute set to None somehow (and despite adding lots of tracing I was unable to find out where.) It appeared to be happening when a second thread processed a request while the cursor was still active.

[Dave Abrahams <dave@…>]

Replying to Dave Abrahams <dave@boost-consulting.com>:

Replying to cboos:

#6236 reported a similar problem with fetchone on an empty result set.

Correction: the result set wasn't empty. It had one row. The cursor was getting its "res" attribute set to None somehow (and despite adding lots of tracing I was unable to find out where.) It appeared to be happening when a second thread processed a request while the cursor was still active.

Further detail: here's what I wrote about it on IRC:

while one thread is iterating through a cursor, bitten.BuildConfigController._render_overview gets called on another thread. It does a repository sync(), which somehow causes the other thread's cursor's .res to be None.

Using psycopg2 made all my problems go away

[Christian Boos]

Does changing poolable = True to poolable = False in trac/db/postgres_backend.py make any difference?

[Dave Abrahams <dave@…>]

Replying to cboos:

Does changing poolable = True to poolable = False in trac/db/postgres_backend.py make any difference?

No.

[Christian Boos]

Replying to Dave Abrahams <dave@…>:

… Using psycopg2 made all my problems go away