v0.2.5 — TidesDB engine v9.2.5 (durability bugs fixed upstream; .tidesdb data dir)

TidesDB MySQL plugin — v0.2.5

Bumps the bundled engine from TidesDB v9.2.0 → v9.2.5. The four durability bugs we carried as 0001-walfix.patch are fixed upstream in v9.2.5; the only patch we still ship is the bloom_filter_new use-after-free fix (TidesDB PR #626). Also moves the default data directory inside the MySQL datadir, and adds two new automated test gates.

Docker image:

docker pull perconalab/tidesdb-mysql:0.2.5

Validation (all gates pass)

Gate	Result
SIGKILL crash-recovery (HammerDB TPC-C, docker kill -9 mid-write)	PASS — no committed-row loss, no order-row gaps
mwbench engine integrity (8.26M keys, 88 peak SSTables, byte-verified)	PASS — 0 lost writes, 0 corrupted values
TPC-C throughput (tuned, durability OFF)	25,624 NOPM @ 40 WH · 23,053 NOPM @ 100 WH, server stable

Full report: docs/v9.2.5-validation-report.md.

What changed

Engine bumped to TidesDB v9.2.5 — 0001-walfix.patch retired

All four durability bugs the walfix patch fixed against v9.2.0 were verified fixed upstream in v9.2.5, one by one:

• convert_sync_mode inversion — the engine sync enum was reordered (NONE=0, FULL=1, INTERVAL=2), making the existing switch correct. ⚠️ Applying the old walfix rewrite to v9.2.5 would now map FULL → NONE and silently re-break durability — which is why the patch is retired, not ported.
• Raw sync_mode at WAL opens — block_manager_open now calls convert_sync_mode internally.
• Unconditional WAL truncate before recovery — tidesdb_create_column_family now validates (preserves) an existing WAL and only truncates a genuinely fresh column family.
• SSTable cursor block_size caching (the v0.2.4 bug #4) — the cursor now caches the real on-disk size only when a block is read from disk, otherwise forces a re-read.

The one fix still required is docker/patches/0001-bloomfix.patch (PR #626): bloom_filter_new free(*bf)'d on its post-malloc failure paths without setting *bf = NULL, leaving a dangling pointer that the unchecked tidesdb_partitioned_merge file_max split path turned into a use-after-free / GPF in bloom_filter_add under heavy compaction.

Per-bug detail and upstream-fix verification: KNOWN-ISSUES.md.

Data directory default moved inside the datadir

The default was a sibling of the datadir (<datadir>/../tidesdb_data) — a MariaDB/TideSQL port artifact that placed engine data where MySQL backup/clone/relocation tooling doesn't expect it. It is now <datadir>/.tidesdb: inside the datadir (same volume/permissions/backup treatment as InnoDB) with a leading dot so it is never mistaken for a schema directory (a bare tidesdb_data would collide with CREATE DATABASE tidesdb_data). tidesdb_data_home_dir still overrides.

Migration: data written by an earlier build lives at the old path; move it into the datadir or set tidesdb_data_home_dir to the old location.

New test gates

• mwbench engine-integrity gate (docker/Dockerfile.mwbench + bench/mwbench/run-mwbench.sh) — builds the upstream mwbench tool against the exact shipped engine and drives heavy ingest + byte-verified concurrent reads + delete/compact, failing on any lost write or corruption. Wired into run-all.sh as a fail-fast step 0.
• Tuned TPC-C throughput profile (bench/hammerdb/run-throughput.sh) — ports tidesdb/hammer's my.cnf.example to MySQL, durability-OFF, with aligned tidesdb/innodb flags for an honest A/B. Not a durability test.

Notes

• perconalab/tidesdb-mysql:latest now points at v0.2.5.
• This remains an experimental build: durable enough that committed data survives a crash, but not something to point production traffic at yet.