Commit Graph

14 Commits

Author SHA1 Message Date
Jussi Saurio
04f9cbfa8d we do not allow DDL inside BEGIN CONCURRENT, so remove test 2025-09-25 11:49:44 +03:00
Jussi Saurio
f7806cbc33 mvcc: add basic checkpoint test 2025-09-25 08:12:13 +03:00
Jussi Saurio
61764bf415 clippy 2025-09-15 11:37:17 +03:00
Jussi Saurio
1fa57b2dec add test demonstrating that issue 3085 can be closed 2025-09-15 11:36:19 +03:00
Jussi Saurio
88856de48e fmt 2025-09-15 11:33:15 +03:00
Jussi Saurio
f2dbf1eeb0 add test demonstrating that issue 3084 can be closed 2025-09-15 11:32:39 +03:00
Jussi Saurio
d643bb2092 add test that demonstrates issue 3083 can be closed 2025-09-15 11:30:56 +03:00
Pekka Enberg
1803d0bb5d test: Enable some MVCC test cases
Suggested by Jussi
2025-09-12 23:11:45 +03:00
Jussi Saurio
305b2f55ae MVCC: remove reliance on BTreeCursor::has_record() 2025-09-12 16:03:55 +03:00
Pekka Enberg
433b60555f Add BEGIN CONCURRENT support for MVCC mode
Currently, when MVCC is enabled, every transaction mode supports
concurrent reads and writes, which makes it hard to adopt for existing
applications that use `BEGIN DEFERRED` or `BEGIN IMMEDIATE`.

Therefore, add support for `BEGIN CONCURRENT` transactions when MVCC is
enabled. The transaction mode allows multiple concurrent read/write
transactions that don't block each other, with conflicts resolved at
commit time. Furthermore, implement the correct semantics for `BEGIN
DEFERRED` and `BEGIN IMMEDIATE` by taking advantage of the pager level
write lock when transaction upgrades to write. This means that now
concurrent MVCC transactions are serialized against the legacy ones when
needed.

The implementation includes:

- Parser support for CONCURRENT keyword in BEGIN statements

- New Concurrent variant in TransactionMode to distinguish from regular
  read/write transactions

- MVCC store tracking of exclusive transactions to support IMMEDIATE and
  EXCLUSIVE modes alongside CONCURRENT

- Proper transaction state management for all transaction types in MVCC

This enables better concurrency for applications that can handle
optimistic concurrency control, while still supporting traditional
SQLite transaction semantics via IMMEDIATE and EXCLUSIVE modes.
2025-09-11 16:05:52 +03:00
Jussi Saurio
5f410fd568 Add missing maybe_update_schema() calls
Connection::query() was not properly checking whether it needs to
refresh its schema.
2025-09-10 22:44:26 +03:00
Pekka Enberg
8161badbf4 core/vdbe: Don't rollback transaction when write upgrade fails
If upgrade from read to write transaction fails, don't roll back the
transaction. Instead restore the transaction into its original state,
which allows deferred transactions that have not read anything to
restart automatically.

Fixes #2984
2025-09-10 10:51:52 +03:00
Jussi Saurio
022f679fab chore: make every CREATE TABLE stmt in entire repo have 1 space after tbl name
`BTreeTable::to_sql` makes us incompatible with SQLite by losing e.g. the original whitespace provided during the CREATE TABLE command.

For now let's fix our tests by regex-replacing every CREATE TABLE in
the entire repo to have exactly 1 space after the table name in the
CREATE TABLE statement.
2025-07-22 11:35:21 +03:00
Diego Reis
9ade79b3ad Do not rollback in TxError
Fixes #2153. Not so sure if SQLite doesn't rollback in more cases, we
should definitively check this out.
2025-07-18 01:11:51 -03:00