Set in-memory WAL information according to last commited frame
- before that pages_in_frames, frame_cache and last_checksum was set to
the latest written (not commited!) frame in the WAL found on disk
Simple example to reproduce the data-loss:
```sh
n=$RANDOM
./target/debug/tursodb data-loss-$n.db 'create table t(x)';
strace -o /dev/null -e fault=pwrite64:error=EIO:when=5 ./target/debug/tursodb data-loss-$n.db 'insert into t values (randomblob(4 * 4096));'
./target/debug/tursodb data-loss-$n.db 'insert into t values (1);'
./target/debug/tursodb data-loss-$n.db 'select x from t;'
```
The main bug which contributes to the data-loss was update of
`last_checksum` to the value from last frame read from WAL while
actually DB must use checksum of last **commited** frame. Due to this
bug, `insert` from third operation used checksum from last **written**
frame, but continued to append wal from the position after last
**committed** frame. So, fourth operation read WAL, detected checksum
mismatch and dropped all frames written by third operation.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2613
We are relying too much on the currently disabled `FaultyQuery` and
`FsyncNoWait` to assert the basic invariant of "the rows we have
inserted/updated/deleted in the database are still there", so adding
that as a separate `Property` here.
Closes#2610
Problem:
sim was generating compound selects like this:
- pick a random `table`
- create a random single SELECT
- create `n` random compound SELECTs (UNION ALL etc)
assign a WHERE clause that always has a condition based on `table`
This can result in e.g.
```
SELECT a FROM foo WHERE bar.x = 'baz'
```
Solution:
Don't base the WHERE clause on a table that might not be referenced
in the query.
Again, the only reason this wasn't caught before was because `FaultyQuery`
and `FsyncNoWait` are the only paths where this is actually tested with an
assertion, and those are both disabled
Closes#2588
SQLite internally implements `.clone` by doing something like piping
`.dump` into a new connection to a database attached to the file you
want. This PR implements that by adding an `ApplyWriter` that implements
`std::fmt::Write`, and refactors our current `.dump` plumbing to work
with any `Write` interface, so we can `.dump` to stdout or `.dump` to a
new connection, therefore cloning the database.
Reviewed-by: Nikita Sivukhin (@sivukhin)
Closes#2590
Add comprehensive documentation for connecting Turso databases to Claude
Code using the built-in MCP management commands.
This PR addresses the need for easier integration between Turso and
Claude Code by providing clear, step-by-step instructions for users who
want to query their databases using natural language.
Reviewed-by: Preston Thorpe <preston@turso.tech>
Closes#2606
Add comprehensive documentation for connecting Turso databases to Claude Code using the built-in MCP management commands.
The new guide includes:
- Quick 3-step setup process
- Visual command breakdown with annotations
- Multiple usage examples (local, absolute paths, project-scoped)
- MCP server management commands
- Example natural language queries users can make
This makes it much easier for developers to integrate their Turso databases with Claude Code without manually configuring JSON files or understanding the underlying MCP protocol details.
bringing #1127 back to life, except better because this doesn't add
Tokio as a dependency for extension lib just for tests.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2418
we spend a shitload of time doing very complex selects in the simulator,
and i'm not sure there has been a lot of gain from them. using up a lot
of the runtime of a simulator run on these can mask other issues.
Reviewed-by: Preston Thorpe <preston@turso.tech>
Closes#2605
as @avinassh pointed out, if we have an error in a `writev` call, it
could go unnoticed and the checkpoint could proceed as expected after
not writing the expected total amt.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2601
## Problem
We have been running the simulator for over a month without ever doing a
check like "did the rows we updated actually get updated" (#2602 ),
because the only properties that check those are - for whatever reason -
`FsyncNoWait` and `FaultyQuery`, and both of those have been disabled
for a long time.
Before we enable `FaultyQuery` again, let's make sure we don't have any
active bugs on `main` that don't depend on IO faults to happen. One of
these was an index-related corruption bug #2599 - already fixed - which
would've been caught by this test (or any similar assertion that just
checks what we updated in the DB, but we didn't have any)
## Solution
Add `Property::ReadYourUpdatesBack`, which essentially just does the
following:
```
UPDATE foo SET <arbitrary columns = arbitrary values> WHERE <arbitrary condition>
-- followed by
SELECT <the same columns> WHERE <the same condition>
```
And asserts that the values are the ones we just set
Reviewed-by: Pedro Muniz (@pedrocarlo)
Closes#2604
