Den 2017-06-07 kl. 17:09, skrev Simon Slavin:
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.
Aha, thank you both for the explanations.
I guess one possible reason for the checkpoint to return an error (when
using a timeout) could be if there is a transaction opened before the
checkpoint call, which is still using the WAL file when the timeout
expires..?
Got any more examples which could make it return an error I should be
aware of?
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
