On 11/22/2013 02:47 PM, Dan Kennedy wrote:
On 11/22/2013 02:39 PM, Sascha Sertel wrote:
Hello everybody,
the app I'm working on heavily relies on use and reuse of prepared
statements, many of them are reset many times but not finalized until
the
end of the application lifetime.
We also switched to WAL journaling mode a while ago and noticed that the
WAL file just keeps growing bigger and bigger, and the checkpointer
never
seems to be able to write everything back into the main database file
and
truncate the WAL file.
The documentation says that the checkpointer only works if there
aren't any
pending transactions or read/write statements, so I'm wondering if that
directly conflicts with having these long-lived prepared statements?
I haven't tried it out yet but I'm also pretty sure that
sqlite3_wal_checkpoint_v2() with eMode SQLITE_CHECKPOINT_RESTART
would be
unable to obtain a lock and eventually fail with SQLITE_BUSY,
possibly for
the same reason?
You should try it. Seems to me that any bug that would prevent
CHECKPOINT_RESTART from succeeding would probably also have
prevented your writers from committing transactions in rollback
mode.
Or perhaps not, it was just pointed out to me. If you have statements
that have been sqlite3_step()ed but not sqlite3_reset(), your app
may be holding a read-transaction open continuously. In this case
the WAL file will grow indefinitely as well. The fix in that case
is to add the missing sqlite3_reset() calls.
Dan.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
