On Mon, Jan 14, 2013 at 09:05:09AM -0800, Adrian Klaver wrote:
> On 01/14/2013 08:30 AM, Brian Sutherland wrote:
> >Hi,
> >
> >I have a plpython stored procedure which sometimes fails when I run my
> >applications automated test suite. The procedure is called hundreds of
> >times during the tests but only fails a few times, often with the
> >following ImportError:
> >
> > Traceback (most recent call last):
> > File "/Users/jinty/.buildout/eggs/setuptools-0.6c11-py2.7.egg/site.py", line 73, in <module>
> > __boot()
> > File "/Users/jinty/.buildout/eggs/setuptools-0.6c11-py2.7.egg/site.py", line 2, in __boot
> > import sys, imp, os, os.path
> > File "/Users/jinty/src/mp/lib/python2.7/os.py", line 49, in <module>
> > import posixpath as path
> > File "/Users/jinty/src/mp/lib/python2.7/posixpath.py", line 15, in <module>
> > import stat
> > ImportError: No module named stat
> >
> >Changing the order in which the tests are run, or running tests
> >individually makes the error move/change or disappear. The behaviour is
> >the same with PostgreSQL versions 9.2.2 and 9.1.7.
> >
> >I have tried (but failed) to reproduce this error in a simple .sql
> >script. Outside of the tests, it always seems to work.
> >
> >Having run into a brick wall debugging this, I'm hoping there's someone
> >here who can help?
>
> Since order seems to be important what test is run prior to the
> function failing versus the test run when it succeeds?
Experimenting, I can get it down to about 3 tests. At that point it
succeeds about 80% of the time and the errors start being more random
(i.e. different modules are unimportable). It also starts erroring
inside the stored procedure itself rather than at "import site" time.
The database backend stops closing the connection immediately.
The 2 preceding tests, in this case, do not call the stored procedure
(or any plpython code) at all.
I'm guessing that it's some kind of race condition, but I wouldn't know
where to start looking.
--
Brian Sutherland