v1.34.0

Changed

• Upgraded Apache Arrow from 23.0.1 to 25.0.0 (two releases: 24.0.0 and 25.0.0). Highlights that matter to GizmoSQL users:

  • Flight SQL protocol groundwork for retiring client-side DML/DDL detection. The protocol now lets servers declare at prepare time whether a statement returns a result set (is_update on ActionCreatePreparedStatementResult, apache/arrow#49498) — the first step toward GizmoSQL client drivers dropping query-vs-update text sniffing for prepared statements. Adoption lands as the ecosystem catches up: the field is protobuf-only in Arrow 25's C++ release (not yet exposed in the C++ Flight SQL server API, so GizmoSQL cannot populate it yet), while Arrow Java has already merged client support.
  • Stricter Arrow IPC validation: the IPC reader now rejects malformed streams and files it previously tolerated — a hardening win for a network-facing server. Note that a non-conforming client producing sloppy IPC could newly see rejections.
  • A formal Arrow security model: the Arrow project published project-wide and C++-specific security documentation covering guarantees when handling untrusted Arrow data — relevant to GizmoSQL since Arrow is our entire wire format.
  • Refreshed bundled gRPC/protobuf stack, bringing the server's network layer up to current security patch levels.
  • ARM64 SVE runtime dispatch: Arrow's vectorized routines now use SVE on capable ARM CPUs (e.g. AWS Graviton 3/4) — a modest boost for GizmoSQL's arm64 builds on the Flight data path.

  Build notes: two of the three local Arrow source patches (the macOS c-ares set_target_properties fix and the cctools_ld libtool-detection regex) were fixed upstream and now no-op; the MSVC SSE-defines guard still applies.

Added

• Full per-execution timeline in instrumentation: sql_executions now records five timestamps and two durations. New columns fetch_start_time (first result batch delivered to the client; NULL if none; can precede execution_end_time since results stream), fetch_end_time (last batch delivered), cursor_close_time (client released the statement/stream), and total_duration_ms (fetch_end_time - execution_start_time, i.e. execution through result delivery) join the existing enqueue_time/execution_start_time/execution_end_time/duration_ms, so queue wait, engine time, time-to-first-row, fetch phase, and idle-open-cursor time are all derivable by subtraction. Added via ADD COLUMN IF NOT EXISTS migrations on all backends (file, PostgreSQL, DuckLake); exposed in the session_activity and execution_details views, with avg_total_duration_ms/max_total_duration_ms added to session_stats.
• cluster_id is now exposed in the instrumentation session_activity and active_sessions views. Both views carry the owning instance's cluster_id (from --cluster-id / GIZMOSQL_CLUSTER_ID; NULL when unset), so activity can be filtered or grouped per cluster in multi-instance deployments. New view columns are appended at the end of each view's column list so existing PostgreSQL-backed catalogs upgrade in place via CREATE OR REPLACE VIEW.

Fixed

• Instrumentation sql_executions.execution_end_time was wildly inconsistent with duration_ms (e.g. duration_ms = 5 for a start→end span of over an hour). The two columns measured different events: duration_ms was stamped when the engine finished executing, while execution_end_time was stamped when the statement was finally closed or re-executed — for a client holding the statement open, hours after the query finished (that moment is still recorded, now under its honest name: cursor_close_time). execution_end_time now marks when the engine finished and is derived as execution_start_time + duration_ms, so end - start always equals duration_ms exactly; the result-delivery phase is tracked separately by fetch_end_time/total_duration_ms. Timestamps are computed from wall-clock offsets captured synchronously, so instrumentation write-queue latency can no longer skew them.