v26.40.0 release notes

[bosconi]

Release notes for the v26.40.0 train. Dates in RC snapshots are provisional until the release ships. One commit is added per snapshot; the final snapshot sets the real dates.

Applied so far: rc.1, rc.2, rc.3, final — the train is complete. final adds no entries: v26.40.0 is exactly one commit ahead of v26.40.0-rc.3, and that commit is the version bump. Nothing shipped between the last RC and the release tag, so the increment is genuinely empty rather than a gap; the release's 19 published entries all live in the rc.1, rc.2, and rc.3 increments.

Dates are now real, not provisional — please confirm them. Cloud 2026-09-02, Self-Managed 2026-09-03. No dates were supplied, so these come from the v26.40.0 tag's commit date (2026-09-02T17:06:24Z) and +1 day. Two checks support them: v26.39.0's tag date was exactly its published Cloud date, and the +1 Self-Managed offset matches v26.39.0, v26.37.0, v26.35.0, and v26.33.0. They supersede the provisional pair (Cloud 2026-09-03 / Self-Managed 2026-09-04) that all three RC snapshots carried, anchored on the rc.1 tag. The release shipped one day earlier than the cadence estimate — the direction rc.1 predicted, since v26.37.0, v26.38.0, and v26.39.0 each did the same.

Merge ordering — this PR currently conflicts with main, by design of how the branch was cut. It was branched from a main that contained none of the v26.38.0, v26.38.1, or v26.39.0 sections, so ## v26.40.0 sits directly above ## v26.38.2 here. Since then #38204 (v26.38.0) and #38383 (v26.39.0) have merged, and main now opens with ## v26.39.0 — hence the conflict. #38365 (v26.38.1) is still open, so resolving the conflict now would only reintroduce it when that PR merges. The resolution is mechanical and belongs to whichever of these merges last: ## v26.40.0 must end up above all of those sections, and its operator-compatibility row at the top of rows:. Left unresolved deliberately rather than by oversight.

For the release owner — decisions worth a look before merge.

• RESOLVED: mcp: return 202 for notifications so MCP SDK clients complete the handshake (MZC-59) #38556 was never picked, and rc.3's narrowed bug fix is the correct final statement. rc.3 published mcp: accept and ignore params on tools/list so clients sending _meta work (MZC-59) #38558, the second of two MZC-59 commits, but not mcp: return 202 for notifications so MCP SDK clients complete the handshake (MZC-59) #38556 ("return 202 for notifications so MCP SDK clients complete the handshake"), and deliberately narrowed its entry to the transport-level fact that build delivers, naming no client as fixed. The open question was whether mcp: return 202 for notifications so MCP SDK clients complete the handshake (MZC-59) #38556 would land in an rc.4 or in final. It did not: no v26.40.0-rc.4 tag exists, the final tag adds only the version bump, and mcp: return 202 for notifications so MCP SDK clients complete the handshake (MZC-59) #38556 is still not an ancestor of it. So no supersession and no merged bullet — the entry stands as written. MZC-59 remains open for SDK-based MCP clients such as Codex in v26.40.0 and should carry to a later train.
• RESOLVED: mcp: correct the developer endpoint's mz_introspection guidance #38462 is in the release, which retires a caveat rc.3 could not settle at the time. agent-skills#55 flagged that its claim about mz_dataflow_arrangement_sizes on pre-v26.40 servers assumed mcp: correct the developer endpoint's mz_introspection guidance #38462 would ship in v26.40, when no v26.40 tag yet existed. The tag now exists and mcp: correct the developer endpoint's mz_introspection guidance #38462 is an ancestor of it, so the mz-optimize-memory entry needs no change. mcp: correct the developer endpoint's mz_introspection guidance #38462 itself stays omitted — rc.1 classified it Borderline as instruction text with no server behavior change, and seeing the whole release does not disturb that call.
• The Iceberg options this train publishes are undocumented at the tag. grep -rn "ACCESS DELEGATION\|OAUTH2 SERVER URL" doc/user/content/ returns nothing, though doc/user/content/sql/create-connection.md is where they belong. The feature section is published anyway because the SQL surface is reachable, unflagged, and tested against a real catalog — but if the docs are not landing in this release, hold the section for the release that documents them.
• Require read privileges for CREATE TABLE ... FROM SOURCE #38480 is a privilege tightening that can break working deployments on upgrade. CREATE TABLE ... FROM SOURCE now requires SELECT on the source and USAGE on its schema. It is published as a bug fix; you may want it called out more prominently than the Bug Fixes list, since affected admins have to grant SELECT before upgrading.
• rc.2's recovery path is deliberately not in the release note. adapter: invalidate expression cache on MV replacement apply #38545 fixes the root cause of a production incident in which environmentd entered a deterministic crash loop. A deployment that applied a replacement on v26.39.x or earlier keeps the stale cache entries until it upgrades, and one already crash-looping needs an enable_expression_cache=false boot to come up at all. Consider whether the upgrade guide or a support note should carry that.
• Nine flag-gated items were held as Borderline in rc.1 pending a call on whether their flags are on in production: CREATE METRIC SINK (enable_metric_sink, false at the tag), object hydration history (hydration_history_collection_interval, Duration::ZERO, which disables collection), hedged persist blob gets (persist_blob_hedged_get_enabled, false), three upsert/batcher spill optimizations (enable_column_paged_batcher / enable_upsert_chunked_stash / enable_upsert_paged_spill, all false), the columnar merge batcher (enable_columnar_merge_batcher, false), the peek row-iteration limit (enable_compute_peek_row_iteration_limit, false), parallel MySQL snapshots (mysql_source_snapshot_parallelism, false), and Console cluster-list usage metrics (usage-metrics-in-cluster-list-CNS121, off). No published entry in any snapshot is behind an off-by-default flag.
• adapter: hydrate migrated builtin MVs before 0dt cut-over #38399 is omitted as a cross-train duplicate. It appears in the v26.40.0 tracking issue as its main merge, but v26.39.0 rc.2 already published it (v26.39.0 release notes #38383), so restating it under v26.40.0 would show the reader the same fix twice in _index.md. Override if you would rather it appear here.
• Cosmetic, your call: the Agent Skills list reads mz-optimize-memory then mcp-developer-analysis — newest increment first, an artifact of each snapshot prepending into the existing list. Both entries are correct; flagging only in case you prefer them reordered before merge.
• Per-snapshot inclusion: rc.1 23 of 86 PRs (26.7% — a property of a small single-week denominator carrying two penetration-test security fixes, a GA graduation, and two multi-PR capabilities, not a loosened bar); rc.2 1 of 1; rc.3 2 of 4; final 0 of 3.
• The final Step 5 verification pass ran in its widened form over all four snapshot directories and the assembled section on this branch, since the increment had no entries of its own: 0 cut, 0 rewritten, 0 merged. All 19 published entries stand as reviewed, and no RC-time Borderline call flipped when re-read with the full release in view.

Snapshot drafts (with PR links) in mz-skills:

• rc.1: release_notes.md / omitted.md
• rc.2: release_notes.md / omitted.md
• rc.3: release_notes.md / omitted.md
• final: release_notes.md / omitted.md

Borderline PRs omitted: rc.1: 17 — review borderline calls, rc.2: 0 — none, rc.3: 0 — none, final: 0 — none