incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
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 09:29:32 GMT
On 2/22/13, Branko Čibej <brane@wandisco.com> wrote:
> On 22.02.2013 10:06, Olemis Lang wrote:
>> On 2/22/13, Olemis Lang <olemis@gmail.com> wrote:
>>> On 2/21/13, Branko Čibej <brane@wandisco.com> wrote:
>>>> On 21.02.2013 22:00, Olemis Lang wrote:
>>>>> On 2/21/13, Branko Čibej <brane@wandisco.com> wrote:
>>>>>> On 20.02.2013 11:43, Jure Zitnik wrote:
>> [...]
>>>> 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 ;) ...
>>> ;)
>>>
>> I forgot ... the only drawbacks I notice up to this point is the
>> interaction with SQLITE_TEMP_STORE . If that is resolved at
>> compilation time , after analyzing interactions table it seems to me
>> that such approach might cause some headaches in practice .
>
> SQLITE_TEMP_STORE is the compile-time default. The pragma directive
> overrides it in the sense that whatever value the compile-time symbol
> has, you can always get in-memory temp store via the pragma. That's
> quite clear from the interactions table, although it took me more than a
> minute to see it when I first read it. :)
>

jftr

0 + any => file
3 + any => memory

so I guess with SQLITE_TEMP_STORE = 0 this would be impossible ?

-- 
Regards,

Olemis.

Mime
View raw message