IF you have two different versions of SQLite linked into the same executable, both accessing the same database, then the problem that the globals work around can happen. It won't happen if different processes use different versions of SQLite (say two versions of the sqlite3 binary, or sqlite3 versus Python, etc), nor is there an issue if a single process with multiple versions linked is used to access different database files (say if one version is part of nss used to access the system certificate database and the other version is what you compile in to access your databases).
The gist of the problem is that if a single process has two file descriptors open on the same file, and one holds a lock, closing the other file descriptor clears the lock. SQLite's Unix VFS puts the close in a global queue to close later to prevent this. -scott On Tue, May 10, 2016 at 2:29 PM, Steve Schow <steve at bstage.com> wrote: > > I would like to understand this issue a little bit better? > > > On May 10, 2016, at 2:31 PM, Richard Hipp <drh at sqlite.org> wrote: >> >> In unix, SQLite has to use global variables to work around the >> well-known design bugs in posix advisory locks. And so if you have >> two different instances of SQLite running on unix, they will use >> different global variables, causing them to break each others locks >> and you will get database corruption. > > > are you saying that on UNIX, if two different versions of the sqlite3 binary > attempt to access a DB file at the same time?then the globals that are used > in the sqlite3 binaries related to locking may be different in the two > different binaries, and may result in DB corruption? > > If that is the case, then although the internal DB file format may be > backwards compatible between versions of sqlite3, its very important that I > take care not to allow two different versions of the SQLITE executable code > attempt to access the DB file at the same time. As long as they are totally > separate non-concurrent accesses, it sounds like it should be fine?but if > they attempt concurrently, then concurrency locking between them can?t be > garaunteed due to changes in the way you are handling it with globals as the > code has evolved. On UNIX anyway. Do I have that right? > > That?s a very important thing to keep in mind with so many different versions > of sqlite3 executable code floating around..its built into python a lot older > then the sqlite3 binary I have installed, which might be different from what > is compiled into fossil, etc.. > > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
