So if I'm reading the documentation correctly: ==== The wal-index is in shared memory, and so technically it does not have to have a name in the host computer filesystem. Custom VFS implementations are free to implement shared memory in any way they see fit, but the default unix and windows drivers that come built-in with SQLite implement shared memory using mmapped files named using the suffix "-shm" and located in the same directory as the database file.
... Early (pre-release) implementations of WAL mode stored the wal-index in volatile shared-memory, such as files created in /dev/shm on Linux or /tmp on other unix systems. The problem with that approach is that processes with a different root directory (changed via chroot) will see different files and hence use different shared memory areas, leading to database corruption. ==== It seems like the only thing preventing WAL from working with read-only databases is this lack of a global namespace for shared memory. This exists in many Linux systems as "/dev/shm", or even "/tmp" would work fine for a lot of users. I totally understand that you can't make this the default, because it could potentially lead to strange behavior with chroot()s and the like. But for those of us with controlled environments who know that all applications using SQLite share the same view of the filesystem, it would be great if we could #define an option which turns this on. For my application, chroot()ed apps are a complete non-issue, whereas lack of read-only DB access is a dealbreaker for WAL (which would really be a shame, the performance benefit is substantial!) I know I could always write my own VFS to do this, but that seems like overkill. :) More importantly, it requires maintenance - I'd probably create my VFS by copying os_unix.c, but then I wouldn't automatically be getting any fixes/updates that you guys make to that file going forward. Best would be if SQLite had a #define like SQLITE_CUSTOM_WAL_LOCATION, which defaults to undefined (and hence you use the same directory as the DB file), but which users could define to "/dev/shm", "/tmp", or some other location to place all the shm files there, globally. The changes in http://www.sqlite.org/src/fdiff?v1=ae173c9f6afaa58b2833a1c95c6cd32021755c42&v2=a76d1952ac7984574701c48b665220b871c5c9a5 are pretty straightforward, so I could probably take a stab at this if you want. What do you guys think? -- Matthew L. Creech _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
