> I don't think so. Just like the older SQLite journal system, it's important > that the WAL files survive through a crash.
I believe WAL file is not a problem here (despite some confusing macro name that Matthew proposed). The problem is SHM file which don't have to survive - SQLite rebuilds it in case if it's missing. Pavel On Thu, Jul 15, 2010 at 12:01 PM, Simon Slavin <slav...@bigfraud.org> wrote: > > On 15 Jul 2010, at 4:52pm, Matthew L. Creech wrote: > >> This exists in many Linux systems as "/dev/shm", or even "/tmp" would >> work fine for a lot of users. > > I don't think so. Just like the older SQLite journal system, it's important > that the WAL files survive through a crash. SQLite finds the WAL file the > next time the database is opened, and uses the contents to restore the > database to a sane and useful state. Most forms of Unix wipe the /tmp > directory during boot, so the WAL file would not survive. And /dev/shm is > sometimes real RAM storage so naturally that will be empty after a boot too. > > These options work fine for read-only databases but read-only databases don't > actually need a WAL file at all. Rather than spend time writing code to move > the WAL file to a different place, it makes more sense to spend that time > writing code so that a WAL file is not made at all for a read-only database. > > Simon. > _______________________________________________ > 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
