On 11/7/62 23:07, Andreas Kretzer wrote:
I'm using SQLITE3 (V3.29.0) on an arm embedded linux (2.6.39) on an ext3 filesystem.Several processes hold the DB open and the "-wal" and "-shm" files exist. if I use 'lsof | fgrep <name of DB>' I can see all processes having all three files open. At least one of the processes uses threads, but every process has just one single DB connection active which is shared among all threads. The compilation of sqlite3 is done with multithreading in mind: sqlite> pragma compile_options; COMPILER=gcc-6.2.0 ENABLE_DBSTAT_VTAB ENABLE_FTS4 ENABLE_JSON1 ENABLE_RTREE ENABLE_STAT3 ENABLE_STMTVTAB ENABLE_UNKNOWN_SQL_FUNCTION ENABLE_UPDATE_DELETE_LIMIT HAVE_ISNAN THREADSAFE=1 I can check, that the database is threadsafe (mode == 1) and is switched to WAL-mode. So far I never noticed any problems dealing with concurrent updates or so. The only thing (tested in depth with V3.15.2 and V3.29.0) is when one process stops and closes the database using sqlite3_close(). This may even be the sqlite3 CLI. That process closes DB (lsof shows that this process has closed its filedescriptors and is not in the listing anymore). Right at the next write access to the DB in the still running process (at least I think that this is exactly the point) the "-wal" and "-shm" files are removed. The sqlite3_exec() function still returns SQLITE3_OK on all following actions, but 'lsof' reports, that this process has opened the "-wal" and "-shm" files, but marked as "deleted". And they are really deleted and none of the upcoming DB changes will ever reach the real DB. What is wrong? I already checked, that my kernel supports POSIX file locking (CONFIG_FILE_LOCKING=yes). What else can I check? Two or more sqlite3 CLI processes started in parallel don't exhibit this behavior.
Does lsof show that your app has a read-lock on the database file (not the *-wal or *-shm files) just before this happens?
Are you executing any PRAGMA statements in the app? "PRAGMA locking_mode=none" for example?
Or are you opening/closing the database file directly at all (separate from SQLite), causing SQLite's locks to be dropped by this POSIX quirk?
https://sqlite.org/howtocorrupt.html#_posix_advisory_locks_canceled_by_a_separate_thread_doing_close_ Dan. _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
