> On Feb 6, 2018, at 4:13 PM, Simon Slavin <slav...@bigfraud.org> wrote:
> 
> Before you call sqlite3_close_v2(), do this:
> <https://sqlite.org/capi3ref.html#sqlite3_next_stmt 
> <https://sqlite.org/capi3ref.html#sqlite3_next_stmt>>
> and deal with any problems.

Actually, I already do that, to log info about the open statements (see my 
earlier email today.)

But that doesn't directly help. This shows me the sqlite3_stmt pointers, but 
not the C++ objects of mine that own them. I'd need to find those and null out 
the statement pointers in them, which means I'd need a data structure that maps 
from a sqlite3_stmt to my object. This is basically the option (a) I sketched 
out. 

There's the additional problem that sometimes there are open statements that 
don't belong to me, like the one in my earlier email that belongs to the FTS4 
extension.

My current plan is to call sqlite3_close() first, then if it fails with 
SQLITE_BUSY I will call sqlite3_db_config() to enable 
SQLITE_DBCONFIG_NO_CKPT_ON_CLOSE, and then call sqlite3_close_v2(). From my 
reading of sqlite3PagerClose() and sqlite3WalClose(), that config flag should 
prevent the WAL from being deleted when the zombie db closes.

—Jens
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to