After code reading, I have discovered that the culprit is the statement journal.
Regardless of TEMP_STORE = MEMORY or not, the statement journal, which is treated differently than a regular journal file, is placed in a temporary file. This effectively kills the usefulness and purpose of the TEMP_STORE directive. Kris Groves wrote: > Hi, > > Just want to bump this, I really need to get to the bottom of this. > > Thanks for any info, > Kris. > > Kris Groves wrote: > >> Hi, >> From what I understand : >> - default behavior is to use files for temporary stuff. >> - the directory that will be used for these temporary files can be >> defined via pragma (temp_store_directory). If the pragma is not used, >> it will default to the first hardcoded directory (linux), in the order >> that follows: /var/tmp, /usr/tmp, /tmp, or finally current directory. >> >> So, in the environment I am running in, either those directories do not >> exist, or are not writable to the user under which the process is >> running. The result being an "error 14: unable to open database file" >> as soon as temporary files are needed. >> >> After a little digging I discover SQLITE_TEMP_STORE compilation flag. >> So I export CFLAGS=-DSQLITE_TEMP_STORE=3, run configure and remake, >> figuring that the temp files will now reside in memory, and need no >> writing into a directory. However, the problem remains. >> >> When I look through the code, there is no instance of SQLITE_TEMP_STORE, >> only TEMP_STORE... So I repeat the above with -DTEMP_STORE. Same result. >> >> Then I add a path that I know is accessible to the user under which the >> process runs, to the azDirs array in the unixGetTempname function. >> Voila.. working now.. >> >> I've retested with default TEMP_STORE and TEMP_STORE compiled in a >> 3(memory only). And regardless of the setting, it only works if there >> is a readable/writable directory... >> >> I would think that if TEMP_STORE=3, then no directory is required ? Is >> this a bug, or am I misunderstanding something ? >> >> Thanks, >> Kris. >> >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> >> > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
