VACUUM is a no-op: vacuum and vacuum2 testfixture tests skipped

[timsehn]

Summary

The vacuum and vacuum2 SQLite testfixture tests are skipped in CI as of PR #316. VACUUM itself is implemented as a no-op for doltlite.

Why VACUUM is a no-op

Prolly trees use content-addressed chunk storage. There are no B-tree pages that fragment over time, so there's nothing for VACUUM to compact.

More critically, sqlite3BtreeCopyFile (which VACUUM uses to swap the compacted DB back into place) only copies root hash pointers between Btree structs — it doesn't transfer the underlying chunk data between chunk stores. This means VACUUM has always silently lost data on doltlite: after VACUUM, the main DB's root hashes point to chunks that only existed in the now-destroyed temp DB's chunk store.

CREATE TABLE t(id INTEGER PRIMARY KEY, val INT);
INSERT INTO t VALUES(1,10),(2,20),(3,30);
SELECT count(*) FROM t;  -- 3
VACUUM;
SELECT count(*) FROM t;  -- 0 (data lost!)

This was true on master before any PR #316 changes. Making VACUUM an explicit no-op (return SQLITE_OK in sqlite3RunVacuum) is safer than silent data loss.

What's skipped

In .github/workflows/test.yml:

• vacuum removed from "SQLite core tests"
• vacuum2 removed from "SQLite additional tests"

These tests validate B-tree page compaction behavior (page counts, free list, auto-vacuum) that doesn't apply to prolly tree storage.

To restore VACUUM

A proper VACUUM implementation would need sqlite3BtreeCopyFile to either:

1. Swap the chunk stores between the source and destination BtShared structs, or
2. Copy all referenced chunks from the source store to the destination store

This is non-trivial because ChunkStore contains heap-allocated arrays (branch refs, tag refs, index entries, pending writes) and file handles that can't be naively memcpy-swapped.

Alternatively, VACUUM could be reimplemented as a prolly-native GC/compaction operation using dolt_gc() instead of SQLite's ATTACH-copy-swap pattern.

[timsehn]

Also skipping crash7 from CI (commit c930704). crash7 tests crash recovery during VACUUM — it intentionally crashes the process mid-VACUUM and verifies the DB recovers correctly. With VACUUM as a no-op, the crash never occurs and 146 of 294 test expectations fail.

Full list of skipped testfixture tests:

• vacuum — VACUUM compaction behavior
• vacuum2 — additional VACUUM scenarios
• crash7 — VACUUM crash recovery

[timsehn]

Also skipping pragma testfixture (commit 08d6bfa). 1 of 234 tests checks PRAGMA schema_version after VACUUM expecting an increment. Since VACUUM is a no-op, schema_version stays unchanged.

Full skip list: vacuum, vacuum2, crash7, pragma

[timsehn]

Updated skip list after investigation:

• vacuum — VACUUM compaction behavior
• vacuum2 — additional VACUUM scenarios
• crash7 — VACUUM crash recovery
• pragma — 1 of 234 tests (pragma-8.2.4.3) checks PRAGMA schema_version after VACUUM expecting increment from 108→109. Can't easily fix because prolly btree's schema_version is derived from a catalog content hash during commit, so the simple counter increment gets overwritten. pragma2 still runs.

Root cause for all: VACUUM is a no-op because sqlite3BtreeCopyFile only copies root hash pointers between Btree structs but doesn't transfer underlying chunk data between chunk stores. VACUUM was silently losing all table data even on master — the no-op is strictly safer.

[timsehn]

Instead of skipping the entire pragma test suite (234 tests), commented out just the single failing test pragma-8.2.4.3 in test/pragma.test and restored pragma to CI.

Updated skip list:

• vacuum — skipped from CI
• vacuum2 — skipped from CI
• crash7 — skipped from CI
• pragma-8.2.4.3 — commented out in test file (expects schema_version 109 after VACUUM, gets 108)

All other pragma tests (233) continue to run.