rovan,

Если WAL лог непрерывно растет, это лишь означает, что невозможно выполнить операцию переноса данных из лога в файл БД. Вероятно, база все время используется читающими потоками и/или производится модификация без закрытия транзакции. Если создать одну бесконечную транзакцию и модифицировать в ней БД, разумеется, WAL лог будет расти неограниченно. Вообще говоря, во всех СУБД подобное проектирование приложения приводит к проблемам. Выходов собственно два - использовать короткие транзакции или создавать отдельный поток для модификации данных (в последнем случае все равно нужно коммитить транзакции, а не держать вечно открытую транзакцию!).

Можно вручную вызывать операцию сжатия WAL-лога, см. http://www.sqlite.org/pragma.html#pragma_wal_checkpoint

rovan,

Попробуйте вызвать wal_checkpoint с аргументом:

rovanПробовал, не помогает.
Придётся отказаться от WAL, до тех пор, пока не решу проблему с пишущими потоками.

Попробуйте вообще отключить транзакции и проверить. А потом добавляйте транзакции по очереди и смотрите, где проблема возникает.

Вот из рассылки SQLite подробное описание, в каких случаях и почему WAL журнал может расти неограниченно:

sqlite-users> Also, can you confirm I understand the following correctly:

> 3) When using SQLITE_CHECKPOINT_PASSIVE, the WAL file will grow as
needed, indefinitely, without ever shrinking.

It is possible. But we hope it's the exception, not the rule.

If a checkpoint runs and copies all WAL data into the database file,
the next writer starts writing into the start of the WAL file again.
The WAL file is not usually truncated (see PRAGMA journal_size_limit
if you want it to be) here. The reason being that it is faster to
overwrite an existing file than it is to truncate one and then start
appending to it.

So, if all goes well, SQLite should start over at the start of the
WAL file after each checkpoint. Preventing the WAL file from growing
indefinitely. There are two things that can go wrong:

* A reader might prevent a checkpointer from copying all data from
the WAL into the database file, or

* While the checkpoint is underway, some other process may be
writing to the database (appending to the WAL file).

If either of the above occur, then the next writer will append to the
WAL file, instead of writing into the start of it. If this happens
every checkpoint, then the WAL file will grow without bound.

Use CHECKPOINT_FULL or CHECKPOINT_RESTART (respectively) to prevent
the two conditions enumerated above.

Отсюда понятно, когда нужно использовать CHECKPOINT_FULL и CHECKPOINT_RESTART... соответственно, попробовав оба варианта, можно установить, читающие или пишущие потоки нам "мешают".