On 20 Sep 2016, at 2:39pm, Jose Arroyo <jose.m.arroyo...@gmail.com> wrote:

> However, this writer process has no control over the reader processes, so
> checkpoints may not necessary complete successfully ("If another connection
> has a read transaction open, then the checkpoint cannot reset the WAL file
> because doing so might delete content out from under the reader"). A large
> WAL means slow queries, which means fewer gaps where a checkpoint could
> finish successfully, so this issue is a bit of a vicious circle.

Okay, I understand your explanation now.  I can't think of any immediate 
obvious solution but I hope others can.

It does seem, however, that your problem is in your reader threads, not your 
writer thread.  I would do my best to ensure that my reader threads exerted 
locks for as little time as possible (maybe by using transactions) and that 
they did not hog the database file (perhaps introducing a mutual sleep for one 
second every ten seconds or every 100 seconds).  This should ensure that your 
writing thread could checkpoint at least that frequently.

But you know your code and the limitations of the API you're working through 
and may know that these aren't possible.

sqlite-users mailing list

Reply via email to