On Tue, Feb 7, 2012 at 9:16 PM, David Barrett <[email protected]>wrote:
> Are you, perhaps, using -DSQLITE_SHM_DIRECTORY when compiling the servers, > >> but failing to use the same -D when compiling the command-line tool? >> > > This is possible -- we haven't been hand-compiling the sqlite3 > command-line binary at the same rate that we've been upgrading the library. > (I didn't realize this was necessary: I thought old binaries were > compatible with newer databases? Ah, but perhaps not when they're actively > being accessed by newer code?) When we upgrade to the latest version, > we'll hand-compile the binary to the same version and try again. > Everything is compatible. Version 3.7.2 and 3.7.10 will interoperate fine. Older command-line shells *are* compatible with newer versions of the library. The -DSQLITE_SHM_DIRECTORY option moves the shared memory file to a different directory. This is a non-standard option, and if you use it, it causes the database to be incompatible, at least with respect to locking and crash recovery. (The file format is the same.) The -DSQLITE_SHM_DIRECTORY option was requested by people interested in high performance since by moving the shared memory file into a /dev/shm filesystem, you do make things go slightly faster. I thought maybe one of your people might have discovered this option and started using it in your server. As long as all processes accessing the database use the same -DSQLITE_SHM_DIRECTORY option, everything will work fine. But if two processes are compiled with different -DSQLITE_SHM_DIRECTORY options and one tries to read a database while another is writing it, errors like the one you are seeing will result. So maybe the servers are using -DSQLITE_SHM_DIRECTORY but the command-line shell is a stock build without the non-standard option, in which case trouble could result. -- D. Richard Hipp [email protected] _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
