On Thu, Jan 17, 2013 at 03:18:09PM +0700, Stuart Bishop wrote:
> On Mon, Jan 14, 2013 at 11:30 PM, Brian Sutherland
> <brian@xxxxxxxxxxxxxxxxx> 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
>
> The first thing that pops out here is that the paths contain
> references to buildout.
Yeah, my test environment is undeniably just too complex :(
> Can you confirm that the exception is actually being received from
> PostgreSQL, or is the error coming from your test harness?
It was definitely from PostgreSQL.
> Is your plpython stored procedure supposed to be using the environment
> constructed by buildout, or the system default environment?
I set PYTHONPATH and PYTHONHOME so that postgres uses my buildout
environment (which is inside a virtualenv :(:(). The hack I use is
undeniably ugly, but does work...
> (we use buildout for our Python code, but our plpythonu stored
> procedures use the stock standard Python environment, as provided by
> the Ubuntu packages).
Sadly, I need to get this running on OSX as that's what our developers
use. On Ubuntu/Debian, I would have definitely used the system python
environment.
> If this is the correct environment, it sounds like you are triggering
> some sort of race condition in the buildout generated .py files. You
> might be able to confirm and/or work around the issue by getting your
> own stanza added to the top of the generated site.py, explicitly
> importing the problematic modules right at the top before any buildout
> magic happens.
I mentioned in a different post, but I did manage to resolve the issue.
OSX has insanely low limits for max open files. Python hit that limit
during the import and hid the real error. Increasing the open file limit
with ulimit before starting postgres resolved the issue. I reported a
bug about it here:
http://bugs.python.org/issue16981
Many thanks for having a look anyway.
--
Brian Sutherland
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
