Modify

Opened 7 years ago

Closed 7 years ago

#1923 closed defect (fixed)

reports don't work with PostgreSQL

Reported by: arthur_kalm Owned by: bobbysmith007
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 7 years ago by bobbysmith007

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 7 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 7 years ago by bobbysmith007

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 7 years ago by bobbysmith007

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 7 years ago by bobbysmith007

  • Resolution set to fixed
  • Status changed from new to 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

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


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

 
Note: See TracTickets for help on using tickets.