On 20.02.2013 11:43, Jure Zitnik wrote:
> Hi,
>
> On 2/20/13 9:58 AM, Olemis Lang wrote:
>> Nonetheless the issue is definitely related to this . I've been
>> tracking down this with PyDev and the source of all evil lays inside
>> `MultiProductSystem.upgrade_environment` method and is quite bizarre .
>> Immediately after executing the statement
>>
>> {{{
>> #!py
>>
>> db("CREATE TEMPORARY TABLE %s_temp AS SELECT %s
>> FROM %s" %
>> (table, cols, table))
>>
>> }}}
>
> Thanks for pointing that out, that is in fact the actual source of the
> problem. According to [1] and [2], sqlite creates temporary database
> on the filesystem and keeps it there until the database connection is
> closed. That happens despite the fact that the main database that
> we're using is in-memory.
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:
http://www.sqlite.org/pragma.html#pragma_temp_store
By the way, the reason for consuming two file handles for every open is
that you need one handle for the actual database, and one for the
current transaction log file.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
