based on #3110closes#3111closes#3113closes#3114
all discovered using `test_multiple_connections_fuzz_mvcc`, so no
separate tests. i can add regression unit/integration tests tomorrow
mvcc: properly remove mutations of rolled back tx
mvstore was not removing deletions made by a tx that rolled back.
deletions are removed by clearing the `end` mark from the row
version.
---
mvcc: properly clear tx states when mvcc tx rolls back
---
mvcc: don't double-rollback on write-write-conflict
handle_program_error() already rolls back if this error happens.
double rollback causes a crash.
Closes#3115
on the main branch, mvcc allows concurrent inserts from multiple
txns even without BEGIN CONCURRENT, and then always hangs whenever
one of the txns tries to commit.
this commit fixes that issue.
…e connection
With BEGIN CONCURRENT, we cannot use the same connection all the time
because there's no way for the transaction manager to know which
transaction belongs to what "session" -- they're all individual
statements executed in the context of the one connection.
Fixes#3093
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#3094
With BEGIN CONCURRENT, we cannot use the same connection all the time
because there's no way for the transaction manager to know which
transaction belongs to what "session" -- they're all individual
statements executed in the context of the one connection.
Fixes#3093
This patch adds checksums to Turso DB. You may check the design here in
the [RFC](https://github.com/tursodatabase/turso/issues/2178).
1. We use reserved bytes (8 bytes) to store the checksums. On every IO
read, we verify that the checksum matches.
2. We use twox hash for checksums.
3. Checksum works only on 4K pages now. It's a small change to enable
for all other sizes, I will send another PR.
4. Right now, it's not possible to switch to different algorithm or turn
off altogether. That will be added in the future PRs.
5. Checksums can be enabled only for new dbs. For existing DBs, we will
disable it.
6. To add checksums for existing DBs, we need vacuum since it would
require rewrite of whole db.
Closes#2840
Retrying fsync() on error was historically not safe ("fsyncgate") and
Postgres still defaults to panicing on fsync(). Therefore, add a
"data_sync_retry" pragma (disabled by default) and use it to determine
whether to panic on fsync() error or not.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#3077
Retrying fsync() on error was historically not safe ("fsyncgate") and
Postgres still defaults to panicing on fsync(). Therefore, add a
"data_sync_retry" pragma (disabled by default) and use it to determine
whether to panic on fsync() error or not.
currently, `io_uring` is setup to handle partial writes for `pwritev`
(will add `pwrite` in subsequent PR), but unix and other IO back-ends
were not correctly setup for this.
Closes#3073
