Modify

Opened 10 years ago

Closed 10 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 10 years ago by Russ Tyndall

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

comment:2 Changed 10 years ago by arthur_kalm

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 10 years ago by Russ Tyndall

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 10 years ago by Russ Tyndall

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 10 years ago by Russ Tyndall

Resolution: fixed
Status: newclosed

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Russ Tyndall.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.