This PR introduces the ability to introduce latency (e.g thread::sleep)
in every File IO operation. There is a new cli option that configures
the probability of introducing latency. Currently, this probability
defaults to 0, as this change has already detected an infinite loop in
`checkpoint`. To see this bug in action run the following command:
`cargo run -p limbo_sim -- --seed 3961479079923545111 --latency_prob 5`
<img width="918" alt="Pasted Graphic 1" src="https://github.com/user-
attachments/assets/dbf38760-b478-45c2-ac8b-a0ddcf98fd23" />
EDIT: Investigating the bug further, I see that it is returning to the
simulator after the disconnect checkpoint, but I have not yet seen this
test end. Maybe it is just taking too long? Something to look further at
Closes#1770
Page 1 must be initialized and written as soon as possible without
marking page as dirty.
OpenEphemeral now requires a state machine to accomodate new
begin_write_tx semantics.
Closes#1839
Makes it easier to test the feature:
```
$ cargo run -- --experimental-indexes
Limbo v0.0.22
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database
limbo> CREATE TABLE t(x);
limbo> CREATE INDEX t_idx ON t(x);
limbo> DROP INDEX t_idx;
```
Closes#1831
Makes it easier to test the feature:
```
$ cargo run -- --experimental-indexes
Limbo v0.0.22
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database
limbo> CREATE TABLE t(x);
limbo> CREATE INDEX t_idx ON t(x);
limbo> DROP INDEX t_idx;
```
Support for simple interactive rollback like:
```sql
create table t (x);
insert into t values (1);
begin;
insert into t values (2);
rollback;
select * from t;
```
This PR also fixes some other issues I found while debugging:
* Checkpoint would never `clear_dirty` on pages in page cache.
* Auto commit for interactive transactions was not respected so any
`insert` after `begin` would flush frames regardless of `auto_commit`
state.
* `max_frame` on wal shared state was being updated after every
`append_frame` which was incorrect, as another transaction would be able
to use that new `max_frame` even tho the transaction could've rolled
back. Instead we update the private copy of `max_frame` and only update
it at the end.
Follow up for later are savepoints which require implementing a
subjournal to track savepoints and their modified pages.
Closes#1825
The example is wrong (imports wrong package), but also duplicates text from
top-level README.md that will change. Let's drop this for now to avoid
confusion.
When `struct Database` is constructed, store `is_empty` as an
`Arc<AtomicBool>` - the value is true if:
1. DB size is zero
2. WAL has no frames
When `struct Pager` is constructed, this `Arc` is simply cloned. When
any connection runs a transaction it will first check `Pager::is_empty`,
and if the DB is empty, it will lock `init_lock` and then check
`is_empty` again, and if it's still true, it allocates page1 and stores
`false` in the `is_empty` `AtomicBool` and drops the lock.
---
Note that Limbo can currently have a zero DB and a WAL with frames, as
we have no special logic for folding page1 to the main DB file during
initialization.
Page 1 allocation currently happens on the first transaction (read or
write, due to having to support `select * from sqlite_schema` on an
empty DB; we should really check how SQLite actually does this.).
Closes#1830
