On Fri, Jan 20, 2017 at 12:58 Nikita Popov <nikita....@gmail.com> wrote:
> > From the docs for sqlite3_close(): > > > If the database connection is associated with unfinalized prepared > > statements or unfinished sqlite3_backup objects then sqlite3_close() > > will leave the database connection open and return SQLITE_BUSY > <http://www.sqlite.org/rescode.html#busy>. > > If sqlite3_close_v2() is called with unfinalized prepared statements > > and/or unfinished sqlite3_backups, then the database connection becomes > > an unusable "zombie" which will automatically be deallocated when the > > last prepared statement is finalized or the last sqlite3_backup is > > finished. The sqlite3_close_v2() interface is intended for use with > > host languages that are garbage collected, and where the order in which > > destructors are called is arbitrary. > > > > > That sounds like it could be the source of the issue. > Ah, that makes more sense that it never hitting that close call because I couldn't find any scenario where we wouldn't get there eventually. So it sounds like we should be calling sqlite3_close_v2() there instead. -Rasmus
