Module shadow_execute 

Shadow-execution module (T3.4 R&D).

Runs the same SQL on a primary node AND a shadow node, then compares the two results. Used for:

• Major-version upgrade validation (T2.1 stage 3): run production-shape queries on the source-version primary and the target-version standby; alert if results diverge.
• Schema-migration validation: shadow a candidate schema change against the live primary; flag plan-shape regressions before promotion.
• Read-replica drift detection: catch silent corruption or replication-lag-induced staleness in CI.

Results are compared by row-count + per-row hash (matches the T0-IT3 checksum design), so non-deterministic orderings are tolerated. The shadow side runs in a tokio task and is fire-and- forget for the application — the application sees only the primary’s result. Drift is reported via ShadowExecuteReport returned from the task handle, or pushed to a channel if the caller wires one in.

Status

Module scaffolding + comparison logic + tests. Wiring this into the live request path (so every Nth query is shadowed) is a follow-up gated on an explicit feature flag — production deployments don’t want surprise duplicate query load.

Structs

ShadowExecuteReport

One shadow-execution result.

Functions

row_set_hash

Order-independent hash of a row set. Each row is hashed individually (xor-fold of FNV-1a over the row’s text-form), then the row hashes are combined with addition (commutative, associative — so row order in the result set doesn’t change the final hash).

shadow_execute

Run sql on primary and shadow concurrently. Returns the primary’s result for the application to consume, plus a shadow report containing the comparison.