Will look into this. From [this comment](https://searchfox.org/mozilla-release/rev/435433ec58bdce688e2af89f808db4e38383d026/dom/cache/DBSchema.cpp#480-483) and the general purpose of `VACUUM`, it's used to rebuild the database file and to repack it into a minimum of disk space. After the code is only run when the schema is mismatched and we haven't introduced a new cache database upgraded since FF 57. So, I think it's bad that this wasn't caught but it's not critical. ``` ```
Bug 1687685 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
From [this comment](https://searchfox.org/mozilla-release/rev/435433ec58bdce688e2af89f808db4e38383d026/dom/cache/DBSchema.cpp#480-483) and the general purpose of `VACUUM`, it's used to rebuild the database file and to repack it into a minimum of disk space. After the code is only run when the schema is mismatched and we haven't introduced a new cache database upgraded since FF 57. So, I think it's bad that this wasn't caught but it's not critical. The attachment is the log when I enabled the "mozStorage:5" and ran the test. I didn't find something suspicious based on "A VACUUM will fail if there is an open transaction on the database connection that is attempting to run the VACUUM. Unfinalized SQL statements typically hold a read transaction open, so the VACUUM might fail if there are unfinalized SQL statements on the same connection. VACUUM (but not VACUUM INTO) is a write operation and so if another database connection is holding a lock that prevents writes, then the VACUUM will fail. " in (https://www.sqlite.org/lang_vacuum.html) I will find another time to dig into this more.