From: | Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> |
---|---|
To: | Brian Sutherland <brian(at)vanguardistas(dot)net> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: plpython intermittent ImportErrors |
Date: | 2013-01-14 23:02:07 |
Message-ID: | 50F48E6F.4090000@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 01/14/2013 09:55 AM, Brian Sutherland wrote:
>>>
>>> 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.
What are the stored procedure errors?
>
> 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.
Just a guess, something is screwing around with sys.path.
>
--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | T. E. Lawrence | 2013-01-14 23:24:14 | Re: Linux Distribution Preferences? |
Previous Message | Adrian Klaver | 2013-01-14 22:58:07 | Re: PostgreSQL 8.4 tar |