Re: plpython intermittent ImportErrors RESOLVED

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?

I finally got out the big hammer. I applied the attached patch to
Python/import.c and started postgres with PYTHONVERBOSE set. I
discovered that the import was failing because the fopen() call on the
module fails with:

# trying /Users/jinty/src/mp/lib/python2.7/linecache.py
Error opening file: Too many open files

So there's at least one bug here, Python should probably raise an
intelligent error message if an import fails because of too many open
files. Reported that here: http://bugs.python.org/issue16981

I had a look at the files open by the process, there were not that many,
so no leaks or anything. Just an utterly insane OSX default maximum open
file descriptors.

Running:

ulimit -n 4096

before starting PostgreSQL resolved my issue completely.

Many thanks to all who helped out!

--
Brian Sutherland