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.klaver@xxxxxxxxx
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
