On 22 Nov 2013, at 7:39am, Sascha Sertel <sascha.ser...@gmail.com> wrote:
> 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? I don't think a locking error is the cause of your ever-growing journal file. I think you hit the nail on the head with the earlier paragraph: it's the long-lived prepared statements. I think it's a natural consequence of never being in a situation where you have no active statements. All statements are entirely enclosed in a transaction. While you have any statements which are not finalized you have open transactions. So SQLite will always have at least one transaction open, and never be able to truncate the WAL file. I could be wrong about that. I don't have intimate knowledge of what _reset() does in terms of an undeclared transaction. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
