Re: [sqlite] Abnormal memory usage when removing rows within nested transaction from a table, referenced by another table via FK,

2014-12-17 Thread Paul
> > I want to confirm that issue is fixed for me. > Thanks again, Dan! > > > Please ignore this update, patch fixes this problem as well. > > > I want to add even more input for this issue. > > I understand why there is implicit savepoint, when I remove row from > > 'parent' table. > > But

Re: [sqlite] Abnormal memory usage when removing rows within nested transaction from a table, referenced by another table via FK,

2014-12-17 Thread Paul
I want to confirm that issue is fixed for me. Thanks again, Dan! Please ignore this update, patch fixes this problem as well. > I want to add even more input for this issue. > I understand why there is implicit savepoint, when I remove row from 'parent' > table. > But why is this also true

Re: [sqlite] Abnormal memory usage when removing rows within nested transaction from a table, referenced by another table via FK,

2014-12-17 Thread Paul
> On 12/16/2014 03:08 PM, Paul wrote: > > The memory is being used by the statement journal, which you have in > > memory. If the app did not set "journal_mode=memory" and > > "temp_store=memory", SQLite would create a really large temp file > > instead of using memory. Which

Re: [sqlite] Abnormal memory usage when removing rows within nested transaction from a table, referenced by another table via FK,

2014-12-17 Thread Paul
I want to add even more input for this issue. I understand why there is implicit savepoint, when I remove row from 'parent' table. But why is this also true for a 'child' table when I perform 'INSERT OR REPLACE'? Removing FK reference disables journal growth. I don't understand... I have a new

Re: [sqlite] Abnormal memory usage when removing rows within nested transaction from a table, referenced by another table via FK,

2014-12-17 Thread Dan Kennedy
On 12/16/2014 03:08 PM, Paul wrote: The memory is being used by the statement journal, which you have in memory. If the app did not set "journal_mode=memory" and "temp_store=memory", SQLite would create a really large temp file instead of using memory. Which would still be sub-optimal, but might

Re: [sqlite] SQLITE_FTS3_MAX_EXPR_DEPTH and upgrading sqlite

2014-12-17 Thread Clemens Ladisch
Ed Willis wrote: > We were on a version which did not have the compile option > SQLITE_FTS3_MAX_EXPR_DEPTH and are moving up to one that does. As it > turns out we have run into a problem with one of our clients where > they hit this limit now where previously the query just worked. Have a look

Re: [sqlite] SQLITE_FTS3_MAX_EXPR_DEPTH and upgrading sqlite

2014-12-17 Thread Dan Kennedy
On 12/16/2014 10:57 PM, Ed Willis wrote: Hello all, Apologies in advance if this question has been asked and answered elsewhere – a (brief, admittedly) search did not turn up anything and so I’m posting this. We’re in the process of upgrading sqlite in our service. We were on a version