Merge 'feat: add PostgreSQL-style sequences and MVCC-safe AUTOINCREMENT' from Glauber Costa

Add CREATE SEQUENCE / DROP SEQUENCE / nextval() / setval() / currval()
as first-class schema objects, and reimplement AUTOINCREMENT on top of
the same infrastructure so it works correctly under MVCC.
Sequences are the standard mechanism for generating monotonically
increasing (or decreasing) identifiers. This commit adds full support
for user-created sequences (`CREATE SEQUENCE name [INCREMENT BY n]
[MINVALUE n] [MAXVALUE n] [START n] [CYCLE | NO CYCLE]`) and the
functions `nextval()`, `setval()`, `currval()`. AUTOINCREMENT tables now
implicitly create a sequence named
`__turso_internal_autoincrement_<table>` so high-water-mark logic is
unified across both features.
## Design: disk is the source of truth
Every sequence is backed by a hidden B-tree table:
```sql
CREATE TABLE "__turso_internal_seq_<name>"(
    value INTEGER PRIMARY KEY,    -- rowid alias = the sequence value
    is_called INTEGER,
    start INTEGER, inc INTEGER,
    min INTEGER, max INTEGER, cycle INTEGER)
```
`value` is `INTEGER PRIMARY KEY` (the rowid alias). The B-tree is keyed
by the sequence value, so `MIN(value)` / `MAX(value)` is an O(1) seek to
the first/last leaf — **the B-tree _is_ the watermark.**
The in-memory `Sequence` is **pure schema data** — `start`, `increment`,
`min`, `max`, `cycle`. No `AtomicI64`, no `is_called` flag, no dirty
bit, no in-process current-value cache. This is a deliberate change from
an earlier in-memory-atomic design, which couldn't be made safe across
processes (multiple workers on the same disk would each maintain their
own atomic and diverge). Reading from disk on every call is the only
design that survives multiprocess WAL, MVCC, and crash-recovery
uniformly.
## nextval execution
At compile time, `nextval()` emits `begin_write_on_database`, making the
statement a write transaction. At runtime the translator emits an RMW
sequence (see `core/translate/sequence.rs::emit_disk_read_nextval`):
1. **`SequenceBeginInnerTx`** — under MVCC, open an autonomous inner
Concurrent tx scoped to this RMW. The outer tx (if any) is saved off.
Under WAL or when the outer tx is exclusive, this is a no-op — the RMW
runs in the outer tx. The single-writer WAL lock provides the same
serialization the inner tx provides under MVCC.
2. Cursor RMW: `Rewind`/`Last` on the backing table → read the single
watermark row → `SequenceComputeNext` opcode computes the next value
from `(current, is_called, start, inc, min, max, cycle)` baked into the
program → `Insert` the new row keyed by the new value (since `value` is
`INTEGER PRIMARY KEY`, distinct nextvals land on distinct B-tree keys
and never key-conflict).
3. **Inline backing-table compaction**: a small loop emitted right after
the insert deletes every row except the new watermark. After every
successful nextval the backing table holds exactly one row. (This used
to run at commit time via `flush_dirty_sequences`, but the
implementation issued nested `prepare_internal()` calls that drove
`pager.io.step()` synchronously and broke the vdbe async contract — the
outer `Statement::step()` would block instead of returning
`StepResult::IO`. Moving the compaction inline fixed that.)
4. For AUTOINCREMENT-backing sequences, mirror the watermark into
`sqlite_sequence` in the same inner tx so SQLite-compat readers see the
high-water mark without needing a checkpoint.
5. **`SequenceCommitInnerTx`** — commit the inner tx. On
`WriteWriteConflict` (against another nextval racing on the same backing
table), `op_sequence_commit_inner_tx` retries the whole RMW with a
bounded budget (`ProgramState::sequence_inner_retry_count`); when the
budget is exhausted it surfaces `LimboError::Busy` so the caller can
retry at their level. The outer tx (if any) is restored.
Why an inner tx under MVCC: a nextval that aborts because its outer tx
rolls back must still leave its watermark advance durable on disk —
otherwise a parallel reader could observe the same value twice (the
first reader sees the in-memory state, the rolled-back tx releases its
disk write, the next reader recomputes and lands on the same value). The
autonomous inner tx commits the backing-table write independent of the
outer tx, so a rolled-back nextval still "consumed" the value. This is
the standard PostgreSQL semantics (rollback does not reclaim nextval'd
values; gaps are expected).
## setval
`setval(seq, value)` can place the watermark anywhere, which can't be
expressed as a conflict-free append (two concurrent `setval(s, 5)`
followed by `setval(s, 3)` are not commutative). It requires an
**exclusive write transaction** and is rejected inside `BEGIN
CONCURRENT`.
## currval
`currval(seq)` is per-connection. It returns the value most recently
emitted by `nextval` or `setval` on _this_ connection. It's a register
lookup populated by the `SetSequenceCurrval` opcode at the tail of every
nextval/setval; it does not touch disk.
## Restart / recovery
On database open, sequences are initialized from disk:
- User sequences: read the single watermark row from each
`__turso_internal_seq_*` backing table.
- AUTOINCREMENT: read `sqlite_sequence` and seed the implicit sequence
to that value.
If a crash occurs after a nextval committed but before its compaction
loop deleted the prior row, the backing table may briefly contain
multiple rows. The compaction always re-runs on the next nextval, and
the open-time read uses `MAX(value)` for ascending or `MIN(value)` for
descending sequences, so multi-row state is recovered cleanly.
The MVCC checkpoint state machine also rewrites `sqlite_sequence` from
the in-schema sequence list during checkpoint, ensuring the on-disk
autoinc state is clean after every checkpoint cycle.
## Testing
- Integration tests covering all sequence operations, concurrent nextval
from multiple connections, AUTOINCREMENT interaction, ATTACH database
sequences, transaction rollback semantics, descending and CYCLE
sequences, and restart-recovery scenarios.
- Simulator (`limbo_sim`): sequence-aware query generation (CREATE/DROP
SEQUENCE, nextval, setval) and the `SequenceMonotonicity` property —
creates a fresh sequence in a reserved namespace, runs N nextvals,
asserts the engine returned `start + k*increment` (or correct CYCLE
wrap).
- Concurrent simulator (`whopper`): dedicated sequence workloads testing
MVCC concurrent nextval, setval exclusivity, in-flight setval that
survives worker death, autocommit and in-tx nextval interleavings, CYCLE
wrap-aware duplicate / wrong-direction tracking, and cross-checkpoint
persistence. New simulator coverage includes `InsertSeqDefault` (INSERT
into table with `DEFAULT (nextval('s'))`) and tracker handling for
sequences advanced through that opaque path.
- SQL tests (sqltest): `sequence.sqltest`, `mvcc_sequence.sqltest`, and
`attach/sequence.sqltest` covering the full feature surface.
Closes #5688

Closes #7137

Author: PThorpe92

bindings/rust/tests/integration_tests.rs

@@ -1795,39 +1795,32 @@ async fn test_ghost_commits() {
     }
 }
 
-/// AUTOINCREMENT is not supported in MVCC mode. Verify that CREATE TABLE
-/// with AUTOINCREMENT fails with a clear error message.
+/// AUTOINCREMENT is supported in MVCC mode via the sequence-backed
+/// implementation: each AUTOINCREMENT table implicitly creates a
+/// `__turso_internal_seq___turso_internal_autoincrement_<table>` backing
+/// table, and rowid allocation goes through the shared Sequence atomic so
+/// concurrent inserts don't conflict on `sqlite_sequence`. Verify CREATE
+/// TABLE with AUTOINCREMENT succeeds and assigns monotonic rowids.
 #[tokio::test(flavor = "multi_thread", worker_threads = 2)]
-async fn test_autoincrement_blocked_in_mvcc() {
+async fn test_autoincrement_works_in_mvcc() {
     let (db, _dir) = setup_mvcc_db("").await;
     let conn = db.connect().unwrap();
 
-    // CREATE TABLE with AUTOINCREMENT should fail
-    let result = conn
-        .execute(
-            "CREATE TABLE t(a INTEGER PRIMARY KEY AUTOINCREMENT, b TEXT)",
-            (),
-        )
-        .await;
-    assert!(
-        result.is_err(),
-        "CREATE TABLE with AUTOINCREMENT should fail in MVCC mode"
-    );
-    let err = result.unwrap_err().to_string();
-    assert!(
-        err.contains("AUTOINCREMENT is not supported in MVCC mode"),
-        "unexpected error: {err}"
-    );
-
-    // Regular tables without AUTOINCREMENT should still work
-    conn.execute("CREATE TABLE t(a INTEGER PRIMARY KEY, b TEXT)", ())
+    conn.execute(
+        "CREATE TABLE t(a INTEGER PRIMARY KEY AUTOINCREMENT, b TEXT)",
+        (),
+    )
+    .await
+    .unwrap();
+    conn.execute("INSERT INTO t(b) VALUES ('one')", ())
         .await
         .unwrap();
-    conn.execute("INSERT INTO t VALUES (1, 'hello')", ())
+    conn.execute("INSERT INTO t(b) VALUES ('two')", ())
         .await
         .unwrap();
-    let count = query_i64(&conn, "SELECT COUNT(*) FROM t").await;
-    assert_eq!(count, 1);
+
+    let max = query_i64(&conn, "SELECT MAX(a) FROM t").await;
+    assert_eq!(max, 2, "AUTOINCREMENT must assign monotonic rowids");
 }
 
 #[tokio::test]

core/connection.rs

@@ -276,3 +276,10 @@ pub const SQLITE_CONSTRAINT_NOTNULL: usize = SQLITE_CONSTRAINT | (5 << 8);
 pub const SQLITE_CONSTRAINT_TRIGGER: usize = SQLITE_CONSTRAINT | (7 << 8);
 pub const SQLITE_FULL: usize = 13; // we want this in autoincrement - incase if user inserts max allowed int
 pub const SQLITE_CONSTRAINT_UNIQUE: usize = 2067;
+// Standard SQLite error code; kept for documentation and potential
+// reuse. The sequence inner-tx wrap used to emit Insn::Halt with this
+// code, but halt()'s constraint catch-all mis-wrapped it; Busy is now
+// returned directly via Err(LimboError::Busy) from
+// op_sequence_commit_inner_tx.
+#[allow(dead_code)]
+pub const SQLITE_BUSY: usize = 5;

core/error.rs

@@ -835,6 +835,10 @@ pub enum ScalarFunc {
     UnionValueFunc,
     UnionTagFunc,
     UnionExtractFunc,
+    // Sequence functions
+    NextVal,
+    CurrVal,
+    SetVal,
 }
 
 impl Deterministic for ScalarFunc {
@@ -948,6 +952,7 @@ impl Deterministic for ScalarFunc {
             | ScalarFunc::UnionValueFunc
             | ScalarFunc::UnionTagFunc
             | ScalarFunc::UnionExtractFunc => true,
+            ScalarFunc::NextVal | ScalarFunc::CurrVal | ScalarFunc::SetVal => false,
         }
     }
 }
@@ -1086,6 +1091,9 @@ impl Display for ScalarFunc {
             Self::UnionValueFunc => "union_value",
             Self::UnionTagFunc => "union_tag",
             Self::UnionExtractFunc => "union_extract",
+            Self::NextVal => "nextval",
+            Self::CurrVal => "currval",
+            Self::SetVal => "setval",
         };
         write!(f, "{str}")
     }
@@ -1232,6 +1240,9 @@ impl ScalarFunc {
             Self::UnionValueFunc => &[2],    // union_value('tag', value)
             Self::UnionTagFunc => &[1],      // union_tag(col)
             Self::UnionExtractFunc => &[2],  // union_extract(col, 'tag')
+            // Sequence functions
+            Self::NextVal | Self::CurrVal => &[1],
+            Self::SetVal => &[2, 3],
         }
     }
 
@@ -1801,6 +1812,10 @@ impl Func {
             "union_value" => Ok(Some(Self::Scalar(ScalarFunc::UnionValueFunc))),
             "union_tag" => Ok(Some(Self::Scalar(ScalarFunc::UnionTagFunc))),
             "union_extract" => Ok(Some(Self::Scalar(ScalarFunc::UnionExtractFunc))),
+            // Sequence functions
+            "nextval" => Ok(Some(Self::Scalar(ScalarFunc::NextVal))),
+            "currval" => Ok(Some(Self::Scalar(ScalarFunc::CurrVal))),
+            "setval" => Ok(Some(Self::Scalar(ScalarFunc::SetVal))),
             _ => Ok(None),
         }
     }

core/function.rs

@@ -123,7 +123,6 @@ use storage::{page_cache::PageCache, sqlite3_ondisk::PageSize};
 use tracing::{instrument, Level};
 use turso_macros::{match_ignore_ascii_case, AtomicEnum};
 use turso_parser::{ast, ast::Cmd, parser::Parser};
-use util::parse_schema_rows;
 
 pub use connection::{resolve_ext_path, Connection, Row, StepResult, SymbolTable};
 pub(crate) use connection::{AtomicTransactionState, TransactionState};
@@ -1973,6 +1972,7 @@ impl Database {
             vdbe_trace: AtomicBool::new(false),
             dml_require_where: AtomicBool::new(false),
             dqs_dml: AtomicBool::new(true),
+            sequence_inner_retries: AtomicU64::new(0),
             mv_tx: RwLock::new(None),
             attached_mv_txs: RwLock::new(HashMap::default()),
             #[cfg(any(test, injected_yields))]
@@ -2008,6 +2008,7 @@ impl Database {
             named_savepoints: RwLock::new(Vec::new()),
             schema_reparse_in_progress: AtomicBool::new(false),
             prepare_context_generation: AtomicU64::new(0),
+            sequence_currvals: RwLock::new(HashMap::default()),
         });
         self.n_connections
             .fetch_add(1, crate::sync::atomic::Ordering::SeqCst);