Bug found by @alpaylan and described here: https://github.com/tursodatab ase/limbo/issues/662#issuecomment-2589756954 The reason is that we were, as a bytecode optimization, marking instructions as constant in places where it was not safe to do so. It is ONLY safe to mark an instruction as constant if the register allocated for the result of that instruction is allocated during the translation of that expression. In the case of e.g. `Unary(Minus, Number)` we were doing the following: ``` limbo> CREATE TABLE likable_fire (captivating_insolacion INTEGER,mirthful_shihab REAL); limbo> INSERT INTO likable_fire VALUES (8358895602713329453, -7435384732.72567), (4233751081339504981, -6653311696.714637); limbo> select * from likable_fire; 8358895602713329453|-6653311696.714637 4233751081339504981|-6653311696.714637 limbo> explain INSERT INTO likable_fire VALUES (8358895602713329453, -7435384732.72567), (4233751081339504981, -6653311696.714637); addr opcode p1 p2 p3 p4 p5 comment ---- ----------------- ---- ---- ---- ------------- -- ------- 0 Init 0 16 0 0 Start at 16 1 InitCoroutine 5 7 2 0 2 Integer 1783463725 2 0 0 r[2]=8358895602713329453 3 Yield 5 15 0 0 4 Integer 1454033237 2 0 0 r[2]=4233751081339504981 5 Yield 5 15 0 0 6 EndCoroutine 5 0 0 0 7 OpenWriteAsync 0 2 0 0 8 OpenWriteAwait 0 0 0 0 9 Yield 5 15 0 0 10 NewRowId 0 1 0 0 11 MakeRecord 2 2 4 0 r[4]=mkrec(r[2..3]) 12 InsertAsync 0 4 1 0 13 InsertAwait 0 0 0 0 14 Goto 0 9 0 0 15 Halt 0 0 0 0 16 Transaction 0 1 0 0 <!-- Reg 3 evaluated in a loop, but marked as "constant" twice, resulting in the first value being overwritten! --> <!-- The reason mark_last_insn_constant() breaks this is because different values are being evaluated into the --> <!-- Same register in a loop --> 17 Real 0 3 0 -7435384732.72567 0 r[3]=-7435384732.72567 18 Real 0 3 0 -6653311696.714637 0 r[3]=-6653311696.714637 19 Goto 0 1 0 0 ``` This PR removes `.mark_last_insn_constant()` from the affected places. We should think about a small abstraction to prevent this going forward Closes #679
Limbo
Limbo is a work-in-progress, in-process OLTP database management system, compatible with SQLite.
Features
Limbo is an in-process OLTP database engine library that has:
- Asynchronous I/O support on Linux with
io_uring - SQLite compatibility [doc] for SQL dialect, file formats, and the C API
- Language bindings for JavaScript/WebAssembly, Rust, Python, and Java
- OS support for Linux, macOS, and Windows
Getting Started
CLI
Install limbo with:
curl --proto '=https' --tlsv1.2 -LsSf \
https://github.com/tursodatabase/limbo/releases/latest/download/limbo-installer.sh | sh
Then use the SQL shell to create and query a database:
$ limbo database.db
Limbo v0.0.6
Enter ".help" for usage hints.
limbo> CREATE TABLE users (id INT PRIMARY KEY, username TEXT);
limbo> INSERT INTO users VALUES (1, 'alice');
limbo> INSERT INTO users VALUES (2, 'bob');
limbo> SELECT * FROM users;
1|alice
2|bob
JavaScript (wip)
Installation:
npm i limbo-wasm
Example usage:
import { Database } from 'limbo-wasm';
const db = new Database('sqlite.db');
const stmt = db.prepare('SELECT * FROM users');
const users = stmt.all();
console.log(users);
Python (wip)
pip install pylimbo
Example usage:
import limbo
con = limbo.connect("sqlite.db")
cur = con.cursor()
res = cur.execute("SELECT * FROM users")
print(res.fetchone())
Developing
Build and run limbo cli:
cargo run --package limbo --bin limbo database.db
Run tests:
cargo test
Test coverage report:
cargo tarpaulin -o html
Note
Generation of coverage report requires tarpaulin binary to be installed. You can install it with
cargo install cargo-tarpaulin
Tip
If coverage fails with "Test failed during run" error and all of the tests passed it might be the result of tarpaulin bug. You can temporarily set dynamic libraries linking manually as a workaround, e.g. for linux
LD_LIBRARY_PATH="$(rustc --print=target-libdir)" cargo tarpaulin -o html.
Run benchmarks:
cargo bench
Run benchmarks and generate flamegraphs:
echo -1 | sudo tee /proc/sys/kernel/perf_event_paranoid
cargo bench --bench benchmark -- --profile-time=5
FAQ
How is Limbo different from libSQL?
Limbo is a research project to build a SQLite compatible in-process database in Rust with native async support. The libSQL project, on the other hand, is an open source, open contribution fork of SQLite, with focus on production features such as replication, backups, encryption, and so on. There is no hard dependency between the two projects. Of course, if Limbo becomes widely successful, we might consider merging with libSQL, but that is something that will be decided in the future.
Publications
- Pekka Enberg, Sasu Tarkoma, Jon Crowcroft Ashwin Rao (2024). Serverless Runtime / Database Co-Design With Asynchronous I/O. In EdgeSys ‘24. [PDF]
- Pekka Enberg, Sasu Tarkoma, and Ashwin Rao (2023). Towards Database and Serverless Runtime Co-Design. In CoNEXT-SW ’23. [PDF] [Slides]
Contributing
We'd love to have you contribute to Limbo! Check out the contribution guide to get started.
License
This project is licensed under the MIT license.
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in Limbo by you, shall be licensed as MIT, without any additional terms or conditions.
