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
Closes#2598
Forbids using an index as the iteration cursor for an `UPDATE` statement
unless either of these is true:
1. The index is not affected by the `UPDATE` statement
2. The search condition on the index is guaranteed to return a maximum
of 1 row, so no iteration will happen
### Note
I have created a follow-up issue about handling this a bit better:
https://github.com/tursodatabase/turso/issues/2600Closes#2599
Closes#2555
## Problem
The main problem we had with the current implementation of
`init_pager()` was that the WAL header was eagerly allocated and written
to disk with a page size, and a potential already-set page size on an
initialized database was not checked. Given this scenario:
- Initialized database with e.g. page size 512 but no WAL
- Tursodb connects to DB
It would not check the database file for the page size and instead would
initialize the WAL header with the default 4096 page size, plus
initialize the `BufferPool` similarly with the wrong size, and then
panic when reading pages from the DB, expecting to read `4096` instead
of `512`, as demonstrated in the reproduction of #2555.
## Fix
1. Add `Database::read_page_size_from_db_header()` method that can be
used in the above cases
2. Initialize the WAL header lazily during the first frame append, using
the existing `WalFile::ensure_header_if_needed()` method, removing the
need to eagerly pass `page_size` when constructing the in-memory
`WalFileShared` structure.
## Reader notes
This PR follows a fairly logical commit-by-commit structure so you'll
preferably want to read it that way.
Reviewed-by: Nikita Sivukhin (@sivukhin)
Closes#2569
## Problem
There are several problems with our current statically allocated
`BufferPool`.
1. You cannot open two databases in the same process with different page
sizes, because the `BufferPool`'s `Arena`s will be locked forever into
the page size of the first database. This is the case regardless of
whether the two `Database`s are open at the same time, or if the first
is closed before the second is opened.
2. It is impossible to even write Rust tests for different page sizes
because of this, assuming the test uses a single process.
## Solution
Make `Database` own `BufferPool` instead of it being statically
allocated, so this problem goes away.
Note that I didn't touch the still statically-allocated
`TEMP_BUFFER_CACHE`, because it should continue to work regardless of
this change. It should only be a problem if the user has two or more
databases with different page sizes open simultaneously, because
`TEMP_BUFFER_CACHE` will only support one pool of a given page size at a
time, so the rest of the allocations will go through the global
allocator instead.
## Notes
I extracted this change out from #2569, because I didn't want it to be
smuggled in without being reviewed as an individual piece.
Reviewed-by: Avinash Sajjanshetty (@avinassh)
Closes#2596
This PR ignores changes from `TURSO_SYNC_TABLE_NAME` meta table in order
to not generate unnecessary push commands when nothing actually changed
on the client side.
Closes#2597
Implements the unlikely(X) function. Removes runtime implementations of
likely(), unlikely() and likelihood(), replacing them with panics if
they reach the VDBE.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2559
Now that we actually implemented the statement parsing around views,
implementing normal SQLite views is relatively trivial, as they are just
an alias to a query.
We'll implement them now to get them out of the way, and then I'll go
back to DBSP
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2591
Problem
There are several problems with our current statically allocated
`BufferPool`.
1. You cannot open two databases in the same process with different
page sizes, because the `BufferPool`'s `Arena`s will be locked forever
into the page size of the first database. This is the case regardless
of whether the two `Database`s are open at the same time, or if the first
is closed before the second is opened.
2. It is impossible to even write Rust tests for different page sizes because
of this, assuming the test uses a single process.
Solution
Make `Database` own `BufferPool` instead of it being statically allocated, so this
problem goes away.
Note that I didn't touch the still statically-allocated `TEMP_BUFFER_CACHE`, because
it should continue to work regardless of this change. It should only be a problem if
the user has two or more databases with different page sizes open simultaneously, because
`TEMP_BUFFER_CACHE` will only support one pool of a given page size at a time, so the rest
of the allocations will go through the global allocator instead.
Notes
I extracted this change out from #2569, because I didn't want it to be smuggled in without
being reviewed as an individual piece.
Sequential is very rarely actually needed, we can very safely use
Acquire / Release for loads/stores, and some of these aren't guarding
anything and can use Relaxed.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2548
