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..
