incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: [RFC] File descriptor overflow running the test suite WAS: [BEP-0003] #355 - Summary of the work done towards multi-product support (2013-02-16)
Date Fri, 22 Feb 2013 08:32:50 GMT
On 2/21/13, Branko Čibej <> wrote:
> On 21.02.2013 22:00, Olemis Lang wrote:
>> On 2/21/13, Branko Čibej <> wrote:
>>> On 20.02.2013 11:43, Jure Zitnik wrote:
>> [...]
>>> Control of the location of temporary databases (hence, temporary tables)
>>> is independent of the type of the main database. You can issue this
>>> statement:
>>>     PRAGMA temp_store = MEMORY;
>>> when you open the sqlite connection, this will override whatever
>>> compile-time default your SQLite installation has and force the
>>> temporary database to be in-memory. See:
>> I wouldn't be against using this ... as long as it won't cause major
>> trouble .
> That depends. This setting is per-connection, so theoretically you could
> use it only during testing or database upgrade, and not during other
> operations.

That was exactly what I was trying to say ... «I wouldn't be against
using this» and «this» = revert to using TEMP table in upgrade method
+ setting PRAGMA in TC's __init__ or setUp (depending on whether we'll
use env stubs with SQLite only or also for other backends , we should
check that too ;) ...

> It also helps if whatever is opening the connections cleans up after
> itself and closes them after it's done,

this is already done since the very time I moved calls to
_setup_test_log into TC's setUp method , I also took these kinds of
precautions `reset_db` et al . In general shoutdown cannot be invoked
with in memory SQLite DB (btw possible for functional TCs ;) , etc ,
etc ... the only fact is that all cleanups happen in tearDown and
fd(s) were opened in __init__ and setUp . So in principle , there was
no chance to control this even if test code was correctly written .

> or you're likely to get dangling
> transactions (eventually) and heisenbugs that, of course, only show up
> at a user's site and cannot be replicated locally. :)

In any case we shall take a look into this ... ;)



View raw message