v26.45.0 release notes - #39477

The v26.45.0 release-note train, one commit per snapshot. Dates in RC snapshots were provisional until the release shipped; the final snapshot sets the real dates.

rc.1 adds the ## v26.45.0 section — 7 Improvements, 1 Agent Skills entry, 7 Bug Fixes (15 published entries from 16 PRs) — and the v26.45 row in the self-managed operator compatibility table. No Features section: nothing in this snapshot's 229 in-scope PRs rises to one. The closest candidate is sum/avg over interval, which fills the last gap in the aggregate surface for a core type rather than adding a capability worth its own heading.

rc.2 adds 1 Bug Fix from 1 PR in scope — zero-downtime cut-overs stalling for hours when the incoming environmentd re-consolidated its whole catalog snapshot before every fence attempt and so lost the race against the serving instance's advancing frontier (#39482). Nothing omitted, nothing Borderline.

rc.3 adds 1 Improvement and amends another, from 2 PRs in scope. New: quieter logins with identity-provider group sync (#39434). Amended in place: rc.1's subject-alternative-name bullet now carries the exact-match pinned-CA carve-out (#39459) and cites both PRs — see the reviewer check below for why that is a replacement rather than a second bullet. Nothing omitted, nothing Borderline.

rc.4 adds nothing, and its commit is intentionally empty. The increment is two items — #39549 (borderline, omitted; see the reviewer check below) and the materialize-bot version-bump commit ba9b30921 — and the provisional dates are unchanged, so there is no edit to make to either file. An RC whose whole increment is a within-train repair is a legitimate outcome rather than a gap; v26.39.0 rc.3 is the precedent for a zero-entry snapshot on this layout, landed the same way. The empty commit is what records rc.4 as applied, so please keep it on any rebase — the commit subject is the ledger that stops a later run re-applying the snapshot.

final adds 1 Agent Skills entry from 6 items in scope (1 materialize version-bump commit, 0 materialize PRs, 5 agent-skills PRs) and sets the real dates. This is the first snapshot of the train whose whole published increment comes from MaterializeInc/agent-skills: GET /compare/v26.45.0-rc.4...v26.45.0 is ahead_by: 1, and that one commit is release: bump to version v26.45.0, touching only bump machinery (Cargo.lock, the eight crate Cargo.tomls, LICENSE, the operator chart, the operator-parameter YAML, and a new SBOM). Nothing was cherry-picked onto the release branch after rc.4. The published entry is agent-skills#90 (mz-debug-freshness operator-cost and headroom corrections); 1 of the remaining 4 is Borderline.

The final commit is preceded on this branch by a merge of main. While the branch sat open it fell 92 commits behind, and an editor consolidated the v26.44.0 and v26.44.1 sections on main into a single ## v26.44.1 with every anchor renamed to {#v26.44.1-…}. The merge brings that in; _index.md now reads ## v26.45.0 → ## v26.44.1 → ## v26.43.0, and the compatibility YAML carries v26.45, v26.44.1, v26.43 in that order. This supersedes the earlier reviewer check about needing a rebase for the v26.44.0 docs PR — #39138 has merged and ## v26.44.0 no longer exists on main.

Release dates: Cloud 2026-10-07, Self-Managed 2026-10-08. Inferred from the v26.45.0 tag's commit date (2026-10-07T17:06:08Z) plus one day, because they were not supplied verbatim — please confirm both with the release owner. They replace the provisional pair rc.1 through rc.4 all carried (Cloud 2026-10-08, Self-Managed 2026-10-09), which anchored on the v26.45.0-rc.1 tag and took the first Thursday strictly after it; the train shipped on the Wednesday instead. That is the sixth train in a row where the Thursday rule overshot by a day. The inferred-from-tag rule checks out against the last two trains: v26.43.0 tagged 2026-09-23 / Cloud 2026-09-23, v26.44.1 tagged 2026-09-30 / Cloud 2026-09-30, both with Self-Managed at +1.

⚠️ Reviewer checks

• ⚠️ The v26.45.0 dates collide with v26.45.1's, and only the release owner can separate them. v26.45.1 was tagged 2026-10-07T18:43:25Z — 1 h 37 min after this tag — and its own final snapshot inferred the identical pair, Cloud 2026-10-07 / Self-Managed 2026-10-08. So _index.md is on course to publish two sections claiming the same Cloud date. Either v26.45.0 reached Cloud and was patched the same day, or v26.45.1 superseded it before or during rollout and is the build Cloud actually received. Whoever answers this should fix both trains. Relatedly: the two v26.45 sections are not consolidated the way the v26.44 pair was — that is an editor's call, and it is entangled with this question.
• An unreported product bug may be hiding in final's one PR, and it is deliberately not published. agent-skills#90 adds skill text saying that before v26.46, EXPLAIN ANALYZE ... CPU has the same per-region overstatement the skill just fixed in its own queries — a claim about server behaviour in this very release. No materialize PR in this train says so, and the skill's warning is the only reachable source, so publishing it would promote one skill author's observation to a product statement. Flagged as a question: if EXPLAIN ANALYZE ... CPU does overstate joins, reductions, and TopK by 1.5x–3x today, that deserves a v26.46 Bug Fixes entry and possibly a known-issue line here.
• rc.4's one PR, #39549, is omitted as borderline, and there is no entry to move if you disagree. It pins jemalloc's allocator page back to 4 KiB on aarch64-unknown-linux-gnu (one line in .cargo/config.toml), repairing a regression #39339 introduced inside this same unreleased train when it bumped jemalloc 5.3.0 → 5.3.1 and silently took the default aarch64 Linux allocator page to 64 KiB. The measured effect is large — at equal post-restart age against v26.44.0, environmentd active-minus-allocated 55 MB → 490 MB and 84 MB → 558 MB on two us-east-1 canaries, the largest canary clusterd pods 0.19 GB → 1.70 GB, local VmRSS 32% higher on environmentd — which is why this is filed Borderline rather than as a plain build omit. It is nonetheless omitted because no released version ever ran the 64 KiB page: build(deps): bump the jemalloc crates #39339 was itself omitted at rc.1 as a dependency bump, so nothing published describes the behaviour, and a user upgrading from v26.44.0 sees the same allocator page before and after. Publishing it would mean writing a bullet asserting that memory use is unchanged from v26.44.0 — a non-statement. If the release owner wants the work visible, an internal sign-off note is the right vehicle, not a release note. Separately worth an eye: this was caught by a release sign-off sweep rather than by CI, and @antiguru confirmed on the PR that "moving to 64kb page size was not a deliberate choice" — a dependency bump that silently changes allocator behaviour may deserve a follow-up guard.
• rc.3 rewrites an rc.1 bullet rather than adding one, and that is deliberate. #39459 repairs a regression #39415 introduced earlier in this same unreleased train, so no released version ever showed the failure and a standalone "fixed" bullet would be false for every reader upgrading from v26.44.0. What it changes for that reader is the scope of rc.1's caveat: a schema registry server certificate byte-for-byte identical to its configured SSL CERTIFICATE AUTHORITY needs no reissue. The narrower alternative, if a reviewer prefers one bullet per snapshot: revert to rc.1's wording and accept a published caveat broader than the shipped behaviour — the safe-direction error, but still wrong. build: pin jemalloc's page size to 4 KiB on aarch64 Linux #39549 above is the same family with a cleaner resolution: there the causing PR was never published, so there was no bullet to amend. final's cross-snapshot pass confirmed the amendment is assembled correctly — one merged Improvements bullet, not two.
• rc.3's group-sync entry is published over the rollout-lever default rule, and the confirmation it asked for is still owed. oidc_group_role_sync_enabled was re-read at the v26.45.0 tag and is still false (src/adapter-types/src/dyncfgs.rs:204, ParameterScope::Environment). Per the rollout-lever rule the code default is advisory, and the entry is published on four grounds: the flag is environment-scoped rather than customer-settable, v26.40.0 rc.1 already published a fix on this same gated path (#38410), the capability was announced GA one release earlier, and the PR ships the new behaviour in the published sync-idp-groups.md page in the same diff. That GA announcement is now live on main as ### SCIM group-to-role mapping is generally available on Materialize Cloud {#v26.44.1-scim-group-to-role-mapping}, which strengthens the call without settling it. If the release owner's answer comes back negative, the entry to cut is the first Improvements bullet — the certificate entry is unaffected.
• Two entries are breaking-ish and need an upgrade-time action, and the notes schema has no "Breaking changes" heading. The stricter Kubernetes API server certificate verification (#39316) and the schema registry / COPY FROM subject-alternative-name requirement (#39415 + #39459) both sit in Improvements, phrased around the action a user must take. A reviewer may want them moved or called out more loudly. Related and omitted: #39351 moves all S3/AWS traffic onto rustls and webpki — if the same SAN strictness applies to a custom S3 endpoint in a Self-Managed deployment, it belongs in the same note; the PR does not say either way.
• Two zero-downtime cut-over fixes are published separately, by design. rc.1's #39151 (previous-generation replicas left running) and rc.2's #39482 (lost fence race against a large catalog audit log) are distinct failures with distinct mechanisms, so they are not merged. final's cross-snapshot pass re-read both with the whole release in view and left them as they are; if a reviewer prefers one combined "zero-downtime cut-over reliability" bullet, that is still an editorial call to make before merge. Also deliberately unpublished on catalog: skip consolidation on syncs that apply no updates #39482: it is a regression since v26.22.0 by the author's own statement, and the fix does not cover syncs that do apply updates (DDL issued during takeover still consolidates the full snapshot) — the PR gives no measurement of that residual, so it is not claimed.
• Curated metric sinks are withheld for the fourth consecutive train (v26.39.0, v26.40.0, v26.42.0, v26.43.0). Three real fixes are Borderline behind enable_metric_sink, which reads false at this tag. Confirm with the release owner: if the flag is on in v26.45.0, publish #39332 (clearest candidate — it also removes the unattributable series from the metric's label set), #38910, and #39337. #39337 deserves a second look even if metric sinks stay off — the coordinator panic it fixes is reachable by any superuser via ALTER SYSTEM SET disabled_metric_sinks = '', a plain system variable with no feature-flag check.
• The schema-registry TLS fix is rc.1's closest call on the include side. #39362's only observed failures are in CI (test/kafka-auth, SS-115) — no customer report, no database-issues reference. It is published because the defect is in shipped code on a shipped path (librdkafka leaves a stale OpenSSL error on the tokio worker's error queue). If a reviewer wants only customer-observed fixes published, this is the entry to cut.
• The introspection-logging latency numbers were measured on one noisy shared machine. #39179's own caveat is not in the published entry, and #39178 adds metrics to confirm the effect elsewhere. A reviewer who wants the figures hedged should say "about 9–14 ms" or cut the halved-SELECT clause, which is the softer of the two claims.
• The materialized-view correction-buffer stack is omitted for want of an end-to-end number. #38894 / #38895 / #38896 are on the default-on path (enable_compute_correction_v2 is true) with real figures — 3503 ms → 1897 ms, 1.6x–2.0x — but every one is a bench of the buffer's own insert path, not of materialized-view ingest. If the compute team can supply a hydration or lag number, publish these as one Improvement; the per-clause provenance is already drafted in the review notes.
• The documented local kind install fails today, and the fix is a docs change. #39149 is omitted as documentation (the rubric excludes the class), but following the guide on v26.42.0 crash-loops environmentd with the exact Invalid Parquet file. Corrupt footer defect that #39115 fixes and this release publishes. Same call as #39125 in v26.44.0 rc.1. If a reviewer restores it, it is a Bug Fix.
• Two PRs are excluded as already published by an earlier train — #39300 (published in v26.44.1 as "Lower balancerd memory use per connection") and #39130 (the materialize half of the materialize-docs → mz-docs rename, whose user-visible half shipped in v26.44.0). Accounted for in omitted.md under "Already published in an earlier release".

Inclusion rate: rc.1 is 7.0% (16/229), inside the usual 5–15% band; rc.2 is 1/1, rc.3 is 2/2, rc.4 is 0/2 and final is 1/6, which is the expected shape for a late RC and a final — the set is cherry-picks a release manager has already filtered down, and at a denominator of one to six the percentage carries no signal. rc.1's denominator is dominated by automation: 125 of the 225 materialize PRs are dependency bumps, 65 of them a single Dependabot fan-out of the materialize-terraform-self-managed modules from 13.10.0 to 13.12.1 across five test/terraform directories — #39282 groups future Terraform releases into one PR so it does not recur. Strip the dependency bumps and rc.1's materialize side is 15 included out of 100 (15%). A further 22 PRs are CI/test-harness repair and 14 are documentation.

The agent-skills windows for rc.2 (2026-10-02T02:23:01Z, 2026-10-02T22:33:36Z] and rc.3 (2026-10-02T22:33:36Z, 2026-10-02T23:08:27Z] are both empty, re-checked against a widened query. MaterializeInc/agent-skills#88 (an automated mz-docs regeneration, omitted as every prior run of that workflow was) lands in rc.4's window (2026-10-02T23:08:27Z, 2026-10-05T14:28:59Z], not final's — rc.2 and rc.3 both predicted final on the assumption that rc.3 was the last candidate, and rc.4 being cut opened a window first. final's window is (2026-10-05T14:28:59Z, 2026-10-07T17:06:08Z] and holds 5 PRs. The windows abut exactly and nothing is double-counted. MaterializeInc/agent-skills#79 merged 15 min 26 s after rc.4's upper bound and falls to final; the margin is small enough that a date-only window would have wrongly pulled it in, so full ISO timestamps were used.

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
• rc.4: release_notes.md / omitted.md
• final: release_notes.md / omitted.md

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