Tags: maxpert/marmot
Tags
v2.9.10-beta: SQLite-native vector search (v5.4) Replaces the Pebble-backed IVF vector index with a fully SQLite-native implementation using CDC-tracked base tables, Vitess AST query rewriting, in-memory vector cache with epoch coherence, and a byte-deterministic cross-node CREATE pipeline. Highlights: - 100K×1264 recall 0.994, p99 1.7ms serial / 3.1ms parallel - k-means|| init: 1M×2048 from ~11h to 74.5s - Shadow-swap REINDEX, auto-retrain, drift tracking - Session vars via @@marmot_vec_* - Replication via AFTER INSERT triggers + notify UDF See commit e0f3236 for full change list.
Fix: Forward handler missing InTransaction and CommittedTxnId 1. handleBegin now returns InTransaction: true so replica knows transaction started after BEGIN. 2. handleDatabaseOp now returns CommittedTxnId so replica can wait for CREATE/DROP DATABASE replication before returning to client. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Fix: Schema version not incremented on followers for CREATE/DROP DATA… …BASE When CREATE/DROP DATABASE transactions committed on follower nodes, the DDLSQL field in CommitResult was not set. This caused the replication handler to skip incrementing the schema version on follower nodes. Effect: After CREATE DATABASE, subsequent DDL (like CREATE TABLE) would fail with "schema version mismatch" because followers had version 0 while coordinator had version 1. Fix: Return DDLSQL in CommitResult for database operations so followers increment their schema version correctly. Verified: WordPress installs and runs correctly on 3-node cluster. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Fix: CREATE/DROP DATABASE forwarding and cleanup dead code - Handle CREATE/DROP DATABASE via coordinator with transpilation enabled so statement type is properly classified and routed to DatabaseManager - Restructure HandleForwardQuery to handle txn control first (no parsing needed) - Add handleDatabaseOp for CREATE/DROP DATABASE operations - Mark unused ctx parameters with _ in handler methods - Fix test failures by checking empty SQL before parsing Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Fix: DDL streaming replication - persist DDL to CDC storage Previously, DDL statements (CREATE/DROP/ALTER TABLE, CREATE/DROP INDEX) were stored only in write intents which were cleaned up after commit. This caused DDL transactions to stream with empty statements, breaking replication to followers. Changes: - Add OpTypeDDL constant for DDL operations in CDC - Add DDLSQL field to EncodedCapturedRow for DDL storage - Add writeDDLToCDC() to persist DDL to /cdc/raw/ during commit - Update sendChangeEvent() to handle OpTypeDDL with DDLChange payload - Fix gap detection in stream_client.go - txn_ids are HLC-based (nanoseconds), not sequential counters, so comparing against transaction count threshold caused infinite snapshot loops DDL replication flow: 1. Leader commit -> writeDDLToCDC() writes to /cdc/raw/ 2. Streaming reads from /cdc/raw/ via IterateCapturedRows() 3. sendChangeEvent() creates DDLChange payload for OpTypeDDL 4. Replica applies DDL via RewriteDDLForIdempotency() Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Fix: CREATE DATABASE via write forwarding fails with syntax error The forward handler created ConnectionSession with TranspilationEnabled=false (the Go default). This caused the coordinator to skip transpilation when parsing forwarded SQL, which resulted in: - CREATE DATABASE being classified as StatementDDL instead of StatementCreateDatabase - Empty database name field (defaulting to session's current database) - SQLite receiving "CREATE DATABASE x" which it doesn't support The fix enables transpilation for forwarded queries, ensuring proper statement type detection for CREATE DATABASE, DROP DATABASE, and other special statements. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
PreviousNext