sqlhunt

Overview ¶

This file adds a SECOND SQL workload to the DST bug hunter, focused on SECONDARY-INDEX maintenance under the commit-fault schedule (commit_unknown / not_committed / too_old retry).

Where the sql-dml workload (sqlhunt.go) probes only the base table's row-model, this one puts a secondary index (idx_k on column k) in the loop: after every batch it checks BOTH the full table (SELECT id,k,v … ORDER BY id) AND, for every key value in the domain, the index-covered point query (SELECT id … WHERE k = <K> ORDER BY id). The second check is the whole point — it exercises the secondary index staying consistent with the base record under retry, and the planner using it. Because the workload is IDEMPOTENT DML (absolute UPDATE SET k=,v= + DELETE), faults must be transparent under autocommit retry, so ANY drift — a stale index entry, a missing index entry, an orphan — is a real fault-induced bug, not a known hazard.

Bare INSERT and relative UPDATE are deliberately excluded (their non-idempotency under commit_unknown is a KNOWN Java-matching hazard); the setup phase that populates the table runs with faults OFF, and only the idempotent statements run with faults ON.

This file adds the "sql-null" workload to the DST bug hunter: a correctness hunt for SQL NULL / three-valued-logic semantics over the full relational stack (parser → Cascades planner → executor → record layer) on SimFDB.

Unlike the fault-idempotency SQL workload (sqlhunt.go), this one runs with FAULTS OFF — the target is *query correctness*, not retry survival, so bare INSERT and every DML shape are fair game (their non-idempotency under commit_unknown is irrelevant with no faults). It drives a random stream of INSERT (with sometimes-NULL columns) / absolute UPDATE / DELETE, keeps a NULL-aware Go row-model in lockstep, and after every batch checks the store against the model on the axes where NULL semantics hide bugs: COUNT(col) vs COUNT(*), NULL-skipping aggregates (SUM/MAX/MIN), IS NULL / IS NOT NULL, and comparison predicates that must exclude NULL rows by three-valued logic.

This file adds a QUERY-CORRECTNESS workload to the DST bug hunter. Where the sql-dml workload (sqlhunt.go) hunts fault-idempotency, this one hunts PLANNER/EXECUTOR correctness — wrong rows, wrong aggregates, bad ORDER BY / LIMIT — with faults OFF.

The shape: a three-column table (id, cat, val) with cat low-cardinality (so filters and groups have multiple rows) and two secondary indexes (on cat and on val) so the Cascades planner has real index-scan choices for the predicate/order/limit queries. A seeded stream of mutations (INSERT new id, absolute UPDATE SET val=<lit>/cat=<lit>, DELETE) is kept in lockstep with a Go row-model, and after every VerifyEvery ops a BATTERY of read queries (COUNT/SUM/MIN/MAX with filters, ORDER BY, LIMIT) is checked against the same result computed INDEPENDENTLY in Go by iterating the model. Any divergence is a real wrong-answer bug the planner or executor produced.

Faults are OFF (hunt.NewSimEnv(seed, 0) / DisabledBuggifier): this workload is not probing commit-fault idempotency, so non-idempotent INSERT is fine and free of the known Java-matching commit_unknown hazard that constrains sqlhunt.go.

Package sqlhunt is a SQL workload for the DST bug hunter: it drives the full relational stack (parser → Cascades planner → executor → record layer) over SimFDB under the same seed loop, fault schedule, shrink, and recording as the record-layer workload — the first example of "add a workload, hunt a new surface" (RFC-199 Tier 2).

It sets a table up faults-free, then runs a random stream of IDEMPOTENT DML (absolute UPDATE + DELETE) under the commit-fault schedule, and after each batch compares the table's full contents to a Go row-model. Idempotent statements make faults transparent under autocommit retry, so any divergence is a real fault-induced SQL bug. Bare INSERT and relative `UPDATE … SET a=a+1` are deliberately excluded: their non-idempotency under commit_unknown is a KNOWN, Java-matching hazard (see TODO.md `## DST findings`), so they'd be known-hazard noise here — characterize those with dedicated regression tests, not this hunt.