Opened 17 years ago
Closed 17 years ago
#1923 closed defect (fixed)
reports don't work with PostgreSQL
Reported by: | arthur_kalm | Owned by: | Russ Tyndall |
---|---|---|---|
Priority: | normal | Component: | TimingAndEstimationPlugin |
Severity: | major | Keywords: | postgresql |
Cc: | akalmenson@… | Trac Release: | 0.10 |
Description
Hi, we're using the plugin with PostgreSQL. When using it in simple projects, the reports from the management tab work well. However, when we try to use the plugin from a relatively large project, and try to view any reports from the management tab (for example, the "Ticket Hours" report), we get the following error:
Traceback (most recent call last): File "/var/lib/python-support/python2.5/trac/web/main.py", line 387, in dispatch_request dispatcher.dispatch(req) File "/var/lib/python-support/python2.5/trac/web/main.py", line 243, in dispatch req.session.save() File "/var/lib/python-support/python2.5/trac/web/session.py", line 177, in save (self.sid,)) File "/var/lib/python-support/python2.5/trac/db/util.py", line 50, in execute return self.cursor.execute(sql_escape_percent(sql), args) File "/var/lib/python-support/python2.5/trac/db/util.py", line 50, in execute return self.cursor.execute(sql_escape_percent(sql), args) File "/usr/lib/python2.5/site-packages/pyPgSQL/PgSQL.py", line 3111, in execute raise OperationalError, msg OperationalError: ERROR: current transaction is aborted, commands ignored until end of transaction block
Attachments (0)
Change History (5)
comment:1 Changed 17 years ago by
comment:2 Changed 17 years ago by
Well for simple projects that have only a few tickets, it works fine, even with python 2.5. We could try our trac instance out with python 2.4, but it's kind of confusing why it works for small projects (a few tickets) and not for larger ones (dozens of tickets).
Regards, Arthur
comment:3 Changed 17 years ago by
Honestly, my best bet is still that on larger datasets, it is exceeding the default timeout length which would cause the tranny to abort.
I am also not familiar whit pyPgSQL/PgSQL.py, but it might be easy to change its default timeout (which could solve this problem). Alternatively, you might try adding a TOP/LIMIT 10 or other such limiting statement to the query to try to reduce the result set which might allow you to better determine if this is a timeout issue.
Sorry I cant be of more assistance at the moment. I am a bit tied up with other projects at the moment. I also do not have an instance of trac running against postegres using that driver, so it would be a fairish amount of work to get your scenario running on my end to recreate the issue.
Cheers,
Russ
comment:4 Changed 17 years ago by
You might want to try updating to the new version I changed the reports a bit based off of someone else's problems with postegres and the reports.
Russ
comment:5 Changed 17 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Given that I have had no update in a month, I will assume that this is fixed. Feel free to reopen if this is not the case
I am not running python 2.5, so it might be a problem with that. It kind of sounds like perhaps the command is timing out or something?
I will try to look into this further a bit later in the week.
Thanks, Russ