Re: [sqlite] SEE Temp Files

> On Jan 29, 2019, at 10:12, Jens Alfke wrote: > >> On Jan 28, 2019, at 3:35 PM, Richard Hipp wrote: >> >> On the other >> hand, if you set SQLITE_TEMP_STORE=2 so that intermediate results are >> held in memory, then intermediate results may be written to swap space >> when the device gets und

Re: [sqlite] SEE Temp Files

> On Jan 28, 2019, at 3:35 PM, Richard Hipp wrote: > > On the other > hand, if you set SQLITE_TEMP_STORE=2 so that intermediate results are > held in memory, then intermediate results may be written to swap space > when the device gets under memory pressure. Mobile OSs don’t swap. (iOS for ce

Re: [sqlite] SEE Temp Files

On 1/28/19, Jim Borden wrote: > I see. That complicates things a bit. What happens to SQLite temp files > when they are "done being used" (if such a concept exists). Are they > deleted or simply left there for the OS to clean up? SQLite calls unlink() immediately after open(). So the OS deall

Re: [sqlite] SEE Temp Files

I see. That complicates things a bit. What happens to SQLite temp files when they are "done being used" (if such a concept exists). Are they deleted or simply left there for the OS to clean up? Jim Borden On 2019/01/29 8:35, "sqlite-users on behalf of Richard Hipp" wrote: Intermedi

Re: [sqlite] SEE Temp Files

Intermediate results may be written into a temp file, if they overflow memory. This could result in an information leak, yes. On the other hand, if you set SQLITE_TEMP_STORE=2 so that intermediate results are held in memory, then intermediate results may be written to swap space when the device g

[sqlite] SEE Temp Files

Having moved from SQLCipher to SEE some time ago, the old advice that SQLCipher gave has stuck with me (from https://www.zetetic.net/sqlcipher/design/ in the Database Encryption and Temporary Files section): “Provided that you taken the important step of disabling file base temporary stores (i.