transaction bug in timingandestimation plugin

0 views
Skip to first unread message

Greg Troxel

unread,
Nov 2, 2009, 12:19:21 PM11/2/09
to bobbysmith, trac-...@googlegroups.com

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

unread,
Nov 2, 2009, 12:57:02 PM11/2/09
to Greg Troxel, trac-...@googlegroups.com
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

Jeff Hammel

unread,
Nov 2, 2009, 1:00:44 PM11/2/09
to trac-...@googlegroups.com
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?
Reply all
Reply to author
Forward
0 new messages