Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Trac: Users

transaction bug in timingandestimation plugin

 

 

Trac users RSS feed   Index | Next | Previous | View Threaded


gdt at ir

Nov 2, 2009, 9:19 AM

Post #1 of 3 (57 views)
Permalink
transaction bug in timingandestimation plugin

I found a lot of pgsql workers showing 'idle in transaction' and over
time this caused a lot of wedging.

I applied the following fix, and it solved the problem. If you think
this is sensible, I'd appreciate it being committed upstream.
(I am still on r5370 via pkgsrc.)


--- tande_filters.py.~1~ 2009-09-16 07:17:06.000000000 -0400
+++ tande_filters.py 2009-11-02 09:13:30.000000000 -0500
@@ -11,7 +11,8 @@

def __init__(self, comp):
self.component = comp
- cur = comp.env.get_db_cnx().cursor()
+ conn = comp.env.get_db_cnx()
+ cur = conn.cursor()
try:
cur.execute("SELECT id FROM custom_report")
self.billing_reports = set([x[0] for x in cur.fetchall()])
@@ -20,6 +21,7 @@
# TimingAndEstimationPlugin isn't installed), silently continue
# without hiding anything.
self.billing_reports = set()
+ conn.commit()
self.component.log.debug('self.billing_reports= %r' % self.billing_reports)

def __call__(self, row_stream):


bobbysmith007 at gmail

Nov 2, 2009, 9:57 AM

Post #2 of 3 (56 views)
Permalink
Re: transaction bug in timingandestimation plugin [In reply to]

This is entirely sensible; I have a module that everything else uses to
get data from the db that already does the ensure commit/close part, but
this code was a contrib from someone else and did not make use of it.
As such I have switched it to using my dbhelper module, which should
prevent this bug in the future.

Thanks for pointing this out (we also use postgres, so I am sure this
would have bitten us eventually). Also FWIW, I have found that the
commit is not necessary on sqlite, so this bug is not apparent there.
Please let me know if you experience further errors!

http://trac-hacks.org/changeset/7000

HTH,
Russ Tyndall


Greg Troxel wrote:
> I found a lot of pgsql workers showing 'idle in transaction' and over
> time this caused a lot of wedging.
>
> I applied the following fix, and it solved the problem. If you think
> this is sensible, I'd appreciate it being committed upstream.
> (I am still on r5370 via pkgsrc.)
>
>
> --- tande_filters.py.~1~ 2009-09-16 07:17:06.000000000 -0400
> +++ tande_filters.py 2009-11-02 09:13:30.000000000 -0500
> @@ -11,7 +11,8 @@
>
> def __init__(self, comp):
> self.component = comp
> - cur = comp.env.get_db_cnx().cursor()
> + conn = comp.env.get_db_cnx()
> + cur = conn.cursor()
> try:
> cur.execute("SELECT id FROM custom_report")
> self.billing_reports = set([x[0] for x in cur.fetchall()])
> @@ -20,6 +21,7 @@
> # TimingAndEstimationPlugin isn't installed), silently continue
> # without hiding anything.
> self.billing_reports = set()
> + conn.commit()
> self.component.log.debug('self.billing_reports= %r' % self.billing_reports)
>
> def __call__(self, row_stream):
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To post to this group, send email to trac-users[at]googlegroups.com
To unsubscribe from this group, send email to trac-users+unsubscribe[at]googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---


jhammel at openplans

Nov 2, 2009, 10:00 AM

Post #3 of 3 (56 views)
Permalink
Re: transaction bug in timingandestimation plugin [In reply to]

On Mon, Nov 02, 2009 at 12:57:02PM -0500, bobbysmith007 wrote:
>
> This is entirely sensible; I have a module that everything else uses to
> get data from the db that already does the ensure commit/close part, but
> this code was a contrib from someone else and did not make use of it.
> As such I have switched it to using my dbhelper module, which should
> prevent this bug in the future.

Any interest in merging your dbhelper with http://trac-hacks.org/wiki/TracSqlHelperScript , which I think I (actually someone else, but I'll take the blame) originally cargo culted from dbhelper?

> Thanks for pointing this out (we also use postgres, so I am sure this
> would have bitten us eventually). Also FWIW, I have found that the
> commit is not necessary on sqlite, so this bug is not apparent there.
> Please let me know if you experience further errors!
>
> http://trac-hacks.org/changeset/7000
>
> HTH,
> Russ Tyndall
>
>
> Greg Troxel wrote:
> > I found a lot of pgsql workers showing 'idle in transaction' and over
> > time this caused a lot of wedging.
> >
> > I applied the following fix, and it solved the problem. If you think
> > this is sensible, I'd appreciate it being committed upstream.
> > (I am still on r5370 via pkgsrc.)
> >
> >
> > --- tande_filters.py.~1~ 2009-09-16 07:17:06.000000000 -0400
> > +++ tande_filters.py 2009-11-02 09:13:30.000000000 -0500
> > @@ -11,7 +11,8 @@
> >
> > def __init__(self, comp):
> > self.component = comp
> > - cur = comp.env.get_db_cnx().cursor()
> > + conn = comp.env.get_db_cnx()
> > + cur = conn.cursor()
> > try:
> > cur.execute("SELECT id FROM custom_report")
> > self.billing_reports = set([x[0] for x in cur.fetchall()])
> > @@ -20,6 +21,7 @@
> > # TimingAndEstimationPlugin isn't installed), silently continue
> > # without hiding anything.
> > self.billing_reports = set()
> > + conn.commit()
> > self.component.log.debug('self.billing_reports= %r' % self.billing_reports)
> >
> > def __call__(self, row_stream):
> >
>
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To post to this group, send email to trac-users[at]googlegroups.com
To unsubscribe from this group, send email to trac-users+unsubscribe[at]googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Trac users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.