You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This commit changes our primary connection initialization code in two
ways to achieve the ability to disable checkpointing the wal.
1) We ignore the initial checkpoint that we call directly into sqlite3
before we restore from bottomless. There is a fixme above that
explains why we need this but to me right now its not totally clear
why without digging deeper into the internals of bottomless. We
should do this but for the moment this unblocks us and from the fixme
comment it does not sound unsafe rather doing extra work potentially.
2) When bottomless needs to get the local change counter is creates a
sqlite connection. When this connection drops it seems like it
checkpoints the wal. I took a brief look at the `sqlite3_close` code
and did not find anything obvious, I have been told in the past that
sqlite3 likes to checkpoint at weird points so this could be one of
those. For the moment, the temporary fix like above is to
`std::mem::forget` the connection so that `Drop` never gets called
and thus `sqlite3_close` never gets called.
With both of these changes we now don't checkpoint the wal unless we hit
the max size or interval (which for testing I have set very high). This
changes are not enabled by default but must be enabled by setting the
following env var:
```
LIBSQL_DISABLE_INIT_CHECKPOINTING=1
```
0 commit comments