l

Will try to set `pragma query_only=0` or `pragma query_only=1` when I get a write or read-only connection to make sure we never write into read-only connection.

> 5 is SQLITE_BUSY, but it indeed should never happen, probably `write_lock()` is forgotten for a write transaction somewhere or so. I made a PR that rules out the possibility...

I cannot reproduce it anymore, but probably because of the network conditions change or something like that. Don't think it is fixed for real, but without the ability to reproduce...

Now that we have `query_only` argument to `Pool.get()` anyway since #6076, maybe we should indeed dedicate a single write connection in the `Pool` and instead of having write mutex in...

But we are never closing connections, so how can this happen? Connections returned to the pool are not closed.

Strange, the largest WAL I have here is 8.7M.

I think I found the reason: we run `PRAGMA incremental_vacuum` via `query_row_optional` that uses read-only connection. With the recent changes it will always fail: ``` sqlite> PRAGMA query_only=1; sqlite> PRAGMA...

We can already close this issue as `query_only` prevents locking the database with a read connection, but for `PRAGMA incremental_vacuum` to work I made a PR #6087.

Regarding WAL I opened an issue https://github.com/deltachat/deltachat-core-rust/issues/6089

#6087 is merged but there was another failure: https://github.com/deltachat/deltachat-core-rust/pull/6087#issuecomment-2430157225