Richard Hipp-3 wrote >> No other active readers or writers. > > Are you sure?
Writers for sure. As far readers are concerned, the things are too complex to make an absolute statement. (I shall check once more.) However, I can add a few observations I made: WAL file size was about 70 MB (as reported by the OS) until the critical table started. The OS started to report 7GB after the commit of the critical table finished. The commit itself took more than 30 min. After the commit the DB size grew by several 100MB. What else could explain this except moving data from WAL to DB? (I.e. WAL reset.) Afterwards several other tables were written (total number of records close to 1 mil), but the WAL file did not grow anymore. After the last table finished, the application was responsive nearly instantly. (No big data movement between WAL and DB.) Finally, the application closed without any delay while deleting the WAL file. (Apparently the WAL file did not contain large amount of unsaved data.) > Because the WAL file should reset automatically after a commit... To make sure that I understand: You mean moving a file pointer, not shrinking of the file itself? (AFAIK, WAL file never shrinks.) P.S. We still use v3.7.15.2. (Would like to upgrade shortly.) P.P.S. I have a copy of all SQLite files. If it helped I could try to read WAL file manually. -- View this message in context: http://sqlite.1065341.n5.nabble.com/Huge-WAL-log-tp79991p79993.html Sent from the SQLite mailing list archive at Nabble.com. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
