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. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users