On 02/07/2018 07:25 AM, Jens Alfke wrote:
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.
That sounds like a pretty good workaround.
There is also now a patch on trunk to avoid this scenario:
http://www.sqlite.org/src/info/4761db83b6d3d57f
Dan.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
