Skip to content

Tags: maxpert/marmot

Tags

v2.9.13-beta

Toggle v2.9.13-beta's commit message
v2.9.13-beta

Beta patch release for live vector encoding hard cut, compact overlay storage, PQ scan tuning, local vector file cleanup, and CDC-driven vector index replication metadata.

v2.9.10-beta

Toggle v2.9.10-beta's commit message
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.

v2.9.9-beta

Toggle v2.9.9-beta's commit message
chore: correct beta version to v2.9.0-beta

- replace all v2.1.0-beta user-facing version strings with v2.9.0-beta

- update runtime startup banners, config headers, docs/examples, and CDC sample source.version

v2.9.8-beta

Toggle v2.9.8-beta's commit message
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>

v2.9.7-beta

Toggle v2.9.7-beta's commit message
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>

v2.9.6-beta

Toggle v2.9.6-beta's commit message
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>

v2.9.2-beta

Toggle v2.9.2-beta's commit message
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>

v2.9.1-beta

Toggle v2.9.1-beta's commit message
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>