On 7 Jun 2017, at 1:49pm, Daniel Polski <dan...@agelektronik.se> wrote:
> Ok, have I understood this correctly: > > If doing a manual checkpoint with SQLITE_CHECKPOINT_TRUNCATE, that call will > block for maximum the time set by the busy_timeout while trying to proceed. > If the busy timeout is 0, the call will return immediately if something > currently is blocking checkpoint progress. > If the busy timeout is set to something > 0, the checkpoint call will retry > to proceed during the timeout. Richard answered the part about checkpoints. In WAL mode, instead of being blocked, a reading thread sees the data as it was when the last transaction finished. This is in contrast to the older non-WAL mode, where reading could block writing. However in both modes, one writing thread will block another. I write about timeouts. If you do not set a timeout, SQLite immediately treats access contention as a fatal error, and returns with SQLITE_BUSY or SQLITE_LOCKED. If you do set a timeout, SQLite will keep attempting access for up to that time. If it eventually gets access it returns with a success result code as if there had never been any problem. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
