On 20 Sep 2016, at 2:39pm, Jose Arroyo <[email protected]> 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.
Simon.
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
