From d3b5931e122dd7a27fc12b42d62808ce7bb0b8ce Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 7 Oct 2026 19:04:11 +0000 Subject: [PATCH 01/10] v26.45.1 release notes (final) Adds the v26.45.1 section to the releases index and the corresponding Self-Managed operator compatibility row. The release contains two commits: a cherry-picked per-subsystem chunk spill gate change (#39659), whose author declares "None. No user-visible change.", and the version bump automation. The section therefore carries dates only. See the mz-skills snapshot draft for the omit reasoning. Dates are the real release dates, inferred from the v26.45.1 tag. --- doc/user/content/releases/_index.md | 4 ++++ .../self_managed/self_managed_operator_compatibility.yml | 5 +++++ 2 files changed, 9 insertions(+) diff --git a/doc/user/content/releases/_index.md b/doc/user/content/releases/_index.md index 13ec8d0105cbd..6d7fd7b2e992a 100644 --- a/doc/user/content/releases/_index.md +++ b/doc/user/content/releases/_index.md @@ -20,6 +20,10 @@ Starting with the v26.1.0 release, Materialize releases on a weekly schedule for both Cloud and Self-Managed. See [Release schedule](/releases/schedule) for details. {{}} +## v26.45.1 +*Released to Materialize Cloud: 2026-10-07*
+*Released to Materialize Self-Managed: 2026-10-08*
+ ## v26.44.1 *Released to Materialize Cloud: 2026-09-30*
*Released to Materialize Self-Managed: 2026-10-01*
diff --git a/doc/user/data/self_managed/self_managed_operator_compatibility.yml b/doc/user/data/self_managed/self_managed_operator_compatibility.yml index 0d68486fc9097..993188c1fbe62 100644 --- a/doc/user/data/self_managed/self_managed_operator_compatibility.yml +++ b/doc/user/data/self_managed/self_managed_operator_compatibility.yml @@ -5,6 +5,11 @@ columns: - column: Release date - column: Notes rows: + - Materialize Operator: v26.45.1 + orchestratord version: v26.45.1 + environmentd version: v26.45.1 + Release date: "2026-10-08" + Notes: "See [v26.45.1 release notes](/releases/#v26451)" - Materialize Operator: v26.44.1 orchestratord version: v26.44.1 environmentd version: v26.44.1 From c98022779cc9a458716f1a60da5cd93008028c39 Mon Sep 17 00:00:00 2001 From: Valerie Chiang Date: Wed, 7 Oct 2026 16:13:51 -0400 Subject: [PATCH 02/10] releases: add Self-Managed alerting and external dependency monitoring to v26.45.1 Co-Authored-By: Claude Opus 5.5 --- doc/user/content/releases/_index.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/doc/user/content/releases/_index.md b/doc/user/content/releases/_index.md index 6d7fd7b2e992a..877d2ba0761c4 100644 --- a/doc/user/content/releases/_index.md +++ b/doc/user/content/releases/_index.md @@ -24,6 +24,31 @@ both Cloud and Self-Managed. See [Release schedule](/releases/schedule) for deta *Released to Materialize Cloud: 2026-10-07*
*Released to Materialize Self-Managed: 2026-10-08*
+### Alerting for Self-Managed {#v26.45.1-alerting} + +*Materialize Self-Managed only* + +Starting with v16.0.0 of the [Materialize Terraform modules](/self-managed-deployments/installation/#install-using-terraform-modules), the monitoring stack ships with ready-made alerts, so you hear about a problem before your users do: + +- **Ready-made alert rules**: 34 alerts are on by default, covering Materialize and the Kubernetes platform under it. They include `environmentd` going down, clusters falling behind or stuck hydrating, replicas nearing their memory limit or being OOM-killed, and panics in Materialize's logs. +- **Route each alert to whoever acts on it**: Every alert carries a severity and an audience, `platform` for the team operating the deployment and `workload` for the teams that own the clusters, so you can send each to the right people. +- **Notify the tools your team already uses**: Configure PagerDuty, Slack, Microsoft Teams, email, or webhook receivers from Terraform. Notifications link to the alert in Grafana and to a pre-filled silence. + +A default install configures no receiver, so alerts notify nobody until you add one. For more information, see [Alerting](/observability/self-managed/alerting/), [Customize alerting](/observability/self-managed/customize-alerting/), and the [list of bundled alerts ⧉](https://materializeinc.github.io/materialize-monitoring/reference/common-alerts/). + +### External dependency monitoring for Self-Managed {#v26.45.1-external-dependencies} + +*Materialize Self-Managed only* + +Materialize depends on object storage, a metadata database, and your cloud provider's infrastructure. Starting with v16.0.0 of the [Materialize Terraform modules](/self-managed-deployments/installation/#install-using-terraform-modules), the monitoring stack shows their health beside Materialize's own, so you can tell quickly whether a problem is in Materialize or in something it depends on: + +- **Materialize Persist (Storage)**: Materialize's view of the object storage that holds its data. +- **Materialize Consensus (Metadata)**: Materialize's view of the metadata database, including whether it is reachable and how long commits take. +- **Infrastructure Cloud Provider**: Metrics pulled from AWS CloudWatch, Google Cloud Monitoring, or Azure Monitor, such as node status checks, compute quota usage, and the metadata database's storage. See [Cloud provider metrics ⧉](https://materializeinc.github.io/materialize-monitoring/metrics/collecting/cloud-provider-metrics/). +- **Metadata database alerts**: `consensus-unreachable` fires when Materialize has not reached the metadata database for five minutes, or your cloud provider reports it down, and `consensus-failures` fires on sustained errors. + +For more information, see [Grafana](/observability/self-managed/grafana/) and the [list of available dashboards ⧉](https://materializeinc.github.io/materialize-monitoring/dashboards/all/). + ## v26.44.1 *Released to Materialize Cloud: 2026-09-30*
*Released to Materialize Self-Managed: 2026-10-01*
From 04a8c2ec88b8bd7d6d65e925275830e54fd4d1b1 Mon Sep 17 00:00:00 2001 From: Valerie Chiang Date: Wed, 7 Oct 2026 16:24:31 -0400 Subject: [PATCH 03/10] releases: tighten v26.45.1 external dependency monitoring entry Co-Authored-By: Claude Opus 5.5 --- doc/user/content/releases/_index.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/doc/user/content/releases/_index.md b/doc/user/content/releases/_index.md index 877d2ba0761c4..4fe67afb6cebf 100644 --- a/doc/user/content/releases/_index.md +++ b/doc/user/content/releases/_index.md @@ -40,14 +40,12 @@ A default install configures no receiver, so alerts notify nobody until you add *Materialize Self-Managed only* -Materialize depends on object storage, a metadata database, and your cloud provider's infrastructure. Starting with v16.0.0 of the [Materialize Terraform modules](/self-managed-deployments/installation/#install-using-terraform-modules), the monitoring stack shows their health beside Materialize's own, so you can tell quickly whether a problem is in Materialize or in something it depends on: +Starting with v16.0.0 of the [Materialize Terraform modules](/self-managed-deployments/installation/#install-using-terraform-modules), you can tell quickly whether a problem is in Materialize or in the object storage and metadata database it depends on: -- **Materialize Persist (Storage)**: Materialize's view of the object storage that holds its data. -- **Materialize Consensus (Metadata)**: Materialize's view of the metadata database, including whether it is reachable and how long commits take. -- **Infrastructure Cloud Provider**: Metrics pulled from AWS CloudWatch, Google Cloud Monitoring, or Azure Monitor, such as node status checks, compute quota usage, and the metadata database's storage. See [Cloud provider metrics ⧉](https://materializeinc.github.io/materialize-monitoring/metrics/collecting/cloud-provider-metrics/). -- **Metadata database alerts**: `consensus-unreachable` fires when Materialize has not reached the metadata database for five minutes, or your cloud provider reports it down, and `consensus-failures` fires on sustained errors. +- **Dashboards**: **Materialize Persist (Storage)** and **Materialize Consensus (Metadata)** show both dependencies as Materialize experiences them. **Infrastructure Cloud Provider** adds what your cloud provider reports about them, once you turn on [cloud provider metrics ⧉](https://materializeinc.github.io/materialize-monitoring/metrics/collecting/cloud-provider-metrics/). +- **Alerts**: `consensus-unreachable`, `consensus-failures`, and `blob-failures` fire when Materialize's calls to the metadata database or object storage keep failing. -For more information, see [Grafana](/observability/self-managed/grafana/) and the [list of available dashboards ⧉](https://materializeinc.github.io/materialize-monitoring/dashboards/all/). +For more information, see the [list of available dashboards ⧉](https://materializeinc.github.io/materialize-monitoring/dashboards/all/). ## v26.44.1 *Released to Materialize Cloud: 2026-09-30*
From b9c12f9591301d7e83b764575fc82b0267870132 Mon Sep 17 00:00:00 2001 From: Valerie Chiang Date: Wed, 7 Oct 2026 16:33:20 -0400 Subject: [PATCH 04/10] releases: move v26.45.1 external dependency monitoring to Improvements, trim alerting Co-Authored-By: Claude Opus 5.5 --- doc/user/content/releases/_index.md | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/doc/user/content/releases/_index.md b/doc/user/content/releases/_index.md index 4fe67afb6cebf..98da7e8c8c883 100644 --- a/doc/user/content/releases/_index.md +++ b/doc/user/content/releases/_index.md @@ -32,20 +32,12 @@ Starting with v16.0.0 of the [Materialize Terraform modules](/self-managed-deplo - **Ready-made alert rules**: 34 alerts are on by default, covering Materialize and the Kubernetes platform under it. They include `environmentd` going down, clusters falling behind or stuck hydrating, replicas nearing their memory limit or being OOM-killed, and panics in Materialize's logs. - **Route each alert to whoever acts on it**: Every alert carries a severity and an audience, `platform` for the team operating the deployment and `workload` for the teams that own the clusters, so you can send each to the right people. -- **Notify the tools your team already uses**: Configure PagerDuty, Slack, Microsoft Teams, email, or webhook receivers from Terraform. Notifications link to the alert in Grafana and to a pre-filled silence. +- **Notify the tools your team already uses**: Configure PagerDuty, Slack, Microsoft Teams, email, or webhook receivers from Terraform. -A default install configures no receiver, so alerts notify nobody until you add one. For more information, see [Alerting](/observability/self-managed/alerting/), [Customize alerting](/observability/self-managed/customize-alerting/), and the [list of bundled alerts ⧉](https://materializeinc.github.io/materialize-monitoring/reference/common-alerts/). +A default install configures no receiver, so alerts notify nobody until you add one. For more information, see [Alerting](/observability/self-managed/alerting/) and [Customize alerting](/observability/self-managed/customize-alerting/). -### External dependency monitoring for Self-Managed {#v26.45.1-external-dependencies} - -*Materialize Self-Managed only* - -Starting with v16.0.0 of the [Materialize Terraform modules](/self-managed-deployments/installation/#install-using-terraform-modules), you can tell quickly whether a problem is in Materialize or in the object storage and metadata database it depends on: - -- **Dashboards**: **Materialize Persist (Storage)** and **Materialize Consensus (Metadata)** show both dependencies as Materialize experiences them. **Infrastructure Cloud Provider** adds what your cloud provider reports about them, once you turn on [cloud provider metrics ⧉](https://materializeinc.github.io/materialize-monitoring/metrics/collecting/cloud-provider-metrics/). -- **Alerts**: `consensus-unreachable`, `consensus-failures`, and `blob-failures` fire when Materialize's calls to the metadata database or object storage keep failing. - -For more information, see the [list of available dashboards ⧉](https://materializeinc.github.io/materialize-monitoring/dashboards/all/). +### Improvements {#v26.45.1-improvements} +- **External dependency monitoring for Self-Managed**: Starting with v15.0.0 of the [Materialize Terraform modules](/self-managed-deployments/installation/#install-using-terraform-modules), new **Materialize Persist (Storage)** and **Materialize Consensus (Metadata)** dashboards show the object storage and metadata database that Materialize depends on, as Materialize experiences them, so you can tell quickly whether a problem is in Materialize or in one of its dependencies. **Infrastructure Cloud Provider** adds what your cloud provider reports about them, once you turn on [cloud provider metrics ⧉](https://materializeinc.github.io/materialize-monitoring/metrics/collecting/cloud-provider-metrics/). See the [list of available dashboards ⧉](https://materializeinc.github.io/materialize-monitoring/dashboards/all/). ## v26.44.1 *Released to Materialize Cloud: 2026-09-30*
From 48c923963137d9951bad514d080f8b536ad47eaa Mon Sep 17 00:00:00 2001 From: Valerie Chiang Date: Wed, 7 Oct 2026 16:43:45 -0400 Subject: [PATCH 05/10] ci: retrigger docs preview Co-Authored-By: Claude Opus 5.5 From 7ab0b767faaed988f43fb6e25fbea81e93e5e0e3 Mon Sep 17 00:00:00 2001 From: Valerie Chiang Date: Wed, 7 Oct 2026 16:47:04 -0400 Subject: [PATCH 06/10] releases: drop external links from v26.45.1 external dependency entry Co-Authored-By: Claude Opus 5.5 --- doc/user/content/releases/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/user/content/releases/_index.md b/doc/user/content/releases/_index.md index 98da7e8c8c883..3254238ffeb2c 100644 --- a/doc/user/content/releases/_index.md +++ b/doc/user/content/releases/_index.md @@ -37,7 +37,7 @@ Starting with v16.0.0 of the [Materialize Terraform modules](/self-managed-deplo A default install configures no receiver, so alerts notify nobody until you add one. For more information, see [Alerting](/observability/self-managed/alerting/) and [Customize alerting](/observability/self-managed/customize-alerting/). ### Improvements {#v26.45.1-improvements} -- **External dependency monitoring for Self-Managed**: Starting with v15.0.0 of the [Materialize Terraform modules](/self-managed-deployments/installation/#install-using-terraform-modules), new **Materialize Persist (Storage)** and **Materialize Consensus (Metadata)** dashboards show the object storage and metadata database that Materialize depends on, as Materialize experiences them, so you can tell quickly whether a problem is in Materialize or in one of its dependencies. **Infrastructure Cloud Provider** adds what your cloud provider reports about them, once you turn on [cloud provider metrics ⧉](https://materializeinc.github.io/materialize-monitoring/metrics/collecting/cloud-provider-metrics/). See the [list of available dashboards ⧉](https://materializeinc.github.io/materialize-monitoring/dashboards/all/). +- **External dependency monitoring for Self-Managed**: Starting with v15.0.0 of the [Materialize Terraform modules](/self-managed-deployments/installation/#install-using-terraform-modules), new **Materialize Persist (Storage)** and **Materialize Consensus (Metadata)** dashboards show the object storage and metadata database that Materialize depends on, as Materialize experiences them, so you can tell quickly whether a problem is in Materialize or in one of its dependencies. **Infrastructure Cloud Provider** adds what your cloud provider reports about them, once you turn on cloud provider metrics. ## v26.44.1 *Released to Materialize Cloud: 2026-09-30*
From 24b265200ae75624a087fd5821a27aafa263b6fc Mon Sep 17 00:00:00 2001 From: Jon Currey Date: Thu, 8 Oct 2026 09:57:23 -0400 Subject: [PATCH 07/10] releases: fold v26.45.0 into v26.45.1 v26.45.0 did not ship, so the v26.45 train releases as v26.45.1, as v26.44 did. Move the v26.45.0 Improvements, Agent Skills, and Bug Fixes entries from #39477 into the v26.45.1 section verbatim, with anchors renamed to {#v26.45.1-...}. Dates, the operator compatibility row, and v26.45.md were already correct for v26.45.1. Co-Authored-By: Claude Opus 5.5 (1M context) --- doc/user/content/releases/_index.md | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/doc/user/content/releases/_index.md b/doc/user/content/releases/_index.md index 3254238ffeb2c..6a4ea8aafe952 100644 --- a/doc/user/content/releases/_index.md +++ b/doc/user/content/releases/_index.md @@ -38,6 +38,28 @@ A default install configures no receiver, so alerts notify nobody until you add ### Improvements {#v26.45.1-improvements} - **External dependency monitoring for Self-Managed**: Starting with v15.0.0 of the [Materialize Terraform modules](/self-managed-deployments/installation/#install-using-terraform-modules), new **Materialize Persist (Storage)** and **Materialize Consensus (Metadata)** dashboards show the object storage and metadata database that Materialize depends on, as Materialize experiences them, so you can tell quickly whether a problem is in Materialize or in one of its dependencies. **Infrastructure Cloud Provider** adds what your cloud provider reports about them, once you turn on cloud provider metrics. +- **Quieter logins with identity-provider group sync**: A login whose token carries organization groups with no matching database role no longer sends the client a `NOTICE` for each one, since roles are now created in Materialize rather than mirrored from the identity provider and unmatched groups are expected; notices for groups that map to reserved role names, and for sync errors in fail-open mode, are unchanged. +- **`sum` and `avg` over `interval`**: `sum(interval)` and `avg(interval)` now work and return `interval`, matching PostgreSQL — `sum` accumulates months, days, and microseconds independently, so `interval '1 month' + interval '40 days'` sums to `1 mon 40 days` rather than being normalized, `avg` carries each fractional component down into the next finer one, and a grouped `sum` whose components exceed the `interval` field widths raises `interval out of range` instead of wrapping silently. +- **Improved compatibility with PostgreSQL ODBC clients**: `expr OPERATOR(pg_catalog.=) expr` and the prefix form `OPERATOR(pg_catalog.-) 1` now parse, so queries psqlODBC routinely generates no longer fail with `Expected operator, found equals sign`; as in PostgreSQL, a function named `operator` must now be quoted. +- **Lower memory for `MIN` and `MAX`**: A materialized view or index computing a single `MIN` or `MAX` over an input that receives updates or deletes no longer keeps an extra copy of its input in memory — for a `MAX` over 100,000 rows in 1,000 groups, the view's arrangements fell from 16.8 MB to 12.8 MB and the first reduction stage from 100,000 records to none under the default bucketing. +- **Lower `SUBSCRIBE` and query latency from introspection logging**: The compute introspection logging dataflow now drains its input in bounded chunks rather than processing a whole interval of events in one uninterruptible call, which on a 4-worker replica serving 1,000 `SUBSCRIBE` timestamps per second took p99 latency for results waiting on the subscribe frontier from 78–86 ms to 9–14 ms and halved the worst per-second index `SELECT` latency. +- **Stricter Kubernetes API server certificate verification in Self-Managed deployments**: The Materialize operator, `environmentd`, and `mz-debug` now verify the Kubernetes API server certificate with rustls rather than OpenSSL, which requires the certificate to carry a subject alternative name matching the address used to reach the API server and rejects a certificate that names the host only in its common name, so clusters with hand-issued API server certificates should confirm their subject alternative names before upgrading; EKS, GKE, AKS, and kind are unaffected. +- **Schema registry and `COPY FROM` server certificates must carry a subject alternative name**: Confluent Schema Registry connections, `COPY FROM` URLs, and the OIDC issuer fetch now reject a server certificate that identifies its host only by common name, so reissue any such certificate with a matching subject alternative name before upgrading; a schema registry server certificate byte-for-byte identical to the one configured as its `SSL CERTIFICATE AUTHORITY` stays trusted and is still matched on its common name when the pinned certificate carries no DNS or IP subject alternative name, but `COPY FROM` and the OIDC issuer fetch have no such exception. +- **Kubernetes events from the Materialize operator**: The operator now publishes Kubernetes events on `Materialize`, `Balancer`, and `Console` resources when it fails to reconcile them, and on each `Materialize` rollout phase, so `kubectl describe` shows why a resource is not progressing; its ClusterRole gains `create` and `patch` on `events.k8s.io` events. + +### Agent Skills {#v26.45.1-agent-skills} +- **`mz-debug-freshness`**: Two corrections to how the skill reads a replica — its operator cost and skew queries now count each plan node's outermost operators only, instead of summing a region's elapsed time on top of the operators nested inside it, which had overstated joins, reductions, and TopK by 1.5x to 3x; and it now judges replica headroom from `heap_percent`, which counts RAM and swap together, rather than `memory_percent`, which counts RAM only and can sit near 100 while a swapping replica still has room. +- **`mz-demo-data`**: A new skill that stands up continuously-updating, realistic synthetic data inside a running Materialize instance using nothing but views over `mz_now()` — no Kafka, no external load generator, and no seed scripts — in a dedicated `materialize_demo` schema that one `DROP SCHEMA` removes. + +### Bug Fixes {#v26.45.1-bug-fixes} +- Fixed zero-downtime deployment cut-overs stalling for hours on environments with a large catalog audit log, where the incoming `environmentd` re-consolidated its entire catalog snapshot before every attempt to fence the serving instance — about 1.1 s against the largest production catalog's 7.4 million audit entries — and so lost the race against that instance's advancing frontier each time, leaving one cut-over waiting 3 h 11 min over roughly 1,700 attempts; a sync that applies no updates now skips the redundant pass. +- Fixed connection poolers losing track of session variables across `DISCARD ALL`, which now reports `ParameterStatus` for every reportable parameter whose value it changed, as `RESET` and PostgreSQL do; with pgbouncer and `server_reset_query_always=1` this had left every client's `application_name` empty. +- Fixed hedged reads from object storage staying disabled for the lifetime of any process that started while the object store or its credential service was unavailable, which was observed during a regional AWS STS outage; the hedge connection is now opened in the background with retries, so it arms once the store recovers, and process startup no longer waits on it. +- Fixed `Invalid Parquet file. Corrupt footer` crashes when reading a large object from an S3-compatible object store that does not return a part count on a part request, and added a length check that turns a short read from any store into a retried failure rather than corrupt data downstream. +- Fixed cluster replicas from an earlier generation being left running during a zero-downtime deployment, where continuous DDL could repeatedly restart the read-only `environmentd` before it finished cleaning up orphaned replicas. +- Fixed `environmentd` and `clusterd` aborting when a MySQL connection, including during connection purification and `VALIDATE CONNECTION`, reached a server that switched authentication to MariaDB `parsec`; the client panic is now returned as a connection error. +- Fixed sporadic schema registry TLS failures caused by a stale OpenSSL error left on the worker thread after creating a Kafka client that reads certificates from `ssl.ca.pem`. +- Fixed the Console reporting different cluster utilization on the cluster list, the cluster detail page, and the utilization charts, which now all show the most recent sample from the same view; fixed memory and CPU readings on multi-process replica sizes (`2xlarge` and larger), which were reported per process rather than merged across processes; and fixed a cluster metrics gauge labeled "Heap Utilization" that showed memory and `0 B` on deployments that run without a heap limit. ## v26.44.1 *Released to Materialize Cloud: 2026-09-30*
From 51f7b12d4535ba9d5cda6f6d8716097ea6592b1a Mon Sep 17 00:00:00 2001 From: Jon Currey Date: Thu, 8 Oct 2026 10:32:39 -0400 Subject: [PATCH 08/10] releases: correct v26.45.1 release dates The train shipped to Cloud on Thursday 2026-10-08 and to Self-Managed on 2026-10-09. The generated dates were the v26.45.0/v26.45.1 tag date (Wednesday 2026-10-07), one day early. Fix the section and the operator compatibility row. Co-Authored-By: Claude Opus 5.5 (1M context) --- doc/user/content/releases/_index.md | 4 ++-- .../data/self_managed/self_managed_operator_compatibility.yml | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/user/content/releases/_index.md b/doc/user/content/releases/_index.md index 6a4ea8aafe952..9fc366f185fe4 100644 --- a/doc/user/content/releases/_index.md +++ b/doc/user/content/releases/_index.md @@ -21,8 +21,8 @@ both Cloud and Self-Managed. See [Release schedule](/releases/schedule) for deta {{}} ## v26.45.1 -*Released to Materialize Cloud: 2026-10-07*
-*Released to Materialize Self-Managed: 2026-10-08*
+*Released to Materialize Cloud: 2026-10-08*
+*Released to Materialize Self-Managed: 2026-10-09*
### Alerting for Self-Managed {#v26.45.1-alerting} diff --git a/doc/user/data/self_managed/self_managed_operator_compatibility.yml b/doc/user/data/self_managed/self_managed_operator_compatibility.yml index 993188c1fbe62..4e13ecc746fe4 100644 --- a/doc/user/data/self_managed/self_managed_operator_compatibility.yml +++ b/doc/user/data/self_managed/self_managed_operator_compatibility.yml @@ -8,7 +8,7 @@ rows: - Materialize Operator: v26.45.1 orchestratord version: v26.45.1 environmentd version: v26.45.1 - Release date: "2026-10-08" + Release date: "2026-10-09" Notes: "See [v26.45.1 release notes](/releases/#v26451)" - Materialize Operator: v26.44.1 orchestratord version: v26.44.1 From deec6cec5856ec38e59c350311e69a80d7629e70 Mon Sep 17 00:00:00 2001 From: Valerie Chiang Date: Thu, 8 Oct 2026 15:14:35 -0400 Subject: [PATCH 09/10] releases: cut unverified and inaccurate v26.45.1 entries Cut entries for changes customers could not hit (MariaDB parsec abort, stale OpenSSL error, Corrupt footer on rustfs) and the group-sync notice change, which is Cloud-only behind a flag that defaults off. Narrow the interval aggregate, orphaned replica, Console utilization, alerting and mz-demo-data entries to what the source PRs support. Co-Authored-By: Claude Opus 5.5 --- doc/user/content/releases/_index.md | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/doc/user/content/releases/_index.md b/doc/user/content/releases/_index.md index 9fc366f185fe4..fdc63a4a6c86f 100644 --- a/doc/user/content/releases/_index.md +++ b/doc/user/content/releases/_index.md @@ -30,7 +30,7 @@ both Cloud and Self-Managed. See [Release schedule](/releases/schedule) for deta Starting with v16.0.0 of the [Materialize Terraform modules](/self-managed-deployments/installation/#install-using-terraform-modules), the monitoring stack ships with ready-made alerts, so you hear about a problem before your users do: -- **Ready-made alert rules**: 34 alerts are on by default, covering Materialize and the Kubernetes platform under it. They include `environmentd` going down, clusters falling behind or stuck hydrating, replicas nearing their memory limit or being OOM-killed, and panics in Materialize's logs. +- **Ready-made alert rules**: 34 alerts are on by default, covering Materialize and the Kubernetes platform under it. They include `environmentd` going down, clusters stuck hydrating, replicas nearing their memory limit or being OOM-killed, and panics in Materialize's logs. - **Route each alert to whoever acts on it**: Every alert carries a severity and an audience, `platform` for the team operating the deployment and `workload` for the teams that own the clusters, so you can send each to the right people. - **Notify the tools your team already uses**: Configure PagerDuty, Slack, Microsoft Teams, email, or webhook receivers from Terraform. @@ -38,8 +38,7 @@ A default install configures no receiver, so alerts notify nobody until you add ### Improvements {#v26.45.1-improvements} - **External dependency monitoring for Self-Managed**: Starting with v15.0.0 of the [Materialize Terraform modules](/self-managed-deployments/installation/#install-using-terraform-modules), new **Materialize Persist (Storage)** and **Materialize Consensus (Metadata)** dashboards show the object storage and metadata database that Materialize depends on, as Materialize experiences them, so you can tell quickly whether a problem is in Materialize or in one of its dependencies. **Infrastructure Cloud Provider** adds what your cloud provider reports about them, once you turn on cloud provider metrics. -- **Quieter logins with identity-provider group sync**: A login whose token carries organization groups with no matching database role no longer sends the client a `NOTICE` for each one, since roles are now created in Materialize rather than mirrored from the identity provider and unmatched groups are expected; notices for groups that map to reserved role names, and for sync errors in fail-open mode, are unchanged. -- **`sum` and `avg` over `interval`**: `sum(interval)` and `avg(interval)` now work and return `interval`, matching PostgreSQL — `sum` accumulates months, days, and microseconds independently, so `interval '1 month' + interval '40 days'` sums to `1 mon 40 days` rather than being normalized, `avg` carries each fractional component down into the next finer one, and a grouped `sum` whose components exceed the `interval` field widths raises `interval out of range` instead of wrapping silently. +- **`sum` and `avg` over `interval`**: `sum(interval)` and `avg(interval)` now work and return `interval`, matching PostgreSQL. - **Improved compatibility with PostgreSQL ODBC clients**: `expr OPERATOR(pg_catalog.=) expr` and the prefix form `OPERATOR(pg_catalog.-) 1` now parse, so queries psqlODBC routinely generates no longer fail with `Expected operator, found equals sign`; as in PostgreSQL, a function named `operator` must now be quoted. - **Lower memory for `MIN` and `MAX`**: A materialized view or index computing a single `MIN` or `MAX` over an input that receives updates or deletes no longer keeps an extra copy of its input in memory — for a `MAX` over 100,000 rows in 1,000 groups, the view's arrangements fell from 16.8 MB to 12.8 MB and the first reduction stage from 100,000 records to none under the default bucketing. - **Lower `SUBSCRIBE` and query latency from introspection logging**: The compute introspection logging dataflow now drains its input in bounded chunks rather than processing a whole interval of events in one uninterruptible call, which on a 4-worker replica serving 1,000 `SUBSCRIBE` timestamps per second took p99 latency for results waiting on the subscribe frontier from 78–86 ms to 9–14 ms and halved the worst per-second index `SELECT` latency. @@ -49,17 +48,14 @@ A default install configures no receiver, so alerts notify nobody until you add ### Agent Skills {#v26.45.1-agent-skills} - **`mz-debug-freshness`**: Two corrections to how the skill reads a replica — its operator cost and skew queries now count each plan node's outermost operators only, instead of summing a region's elapsed time on top of the operators nested inside it, which had overstated joins, reductions, and TopK by 1.5x to 3x; and it now judges replica headroom from `heap_percent`, which counts RAM and swap together, rather than `memory_percent`, which counts RAM only and can sit near 100 while a swapping replica still has room. -- **`mz-demo-data`**: A new skill that stands up continuously-updating, realistic synthetic data inside a running Materialize instance using nothing but views over `mz_now()` — no Kafka, no external load generator, and no seed scripts — in a dedicated `materialize_demo` schema that one `DROP SCHEMA` removes. +- **`mz-demo-data`**: A new skill that stands up continuously-updating, realistic synthetic data inside a running Materialize instance using views over `mz_now()` — no Kafka, no external load generator, and no seed scripts — in a dedicated `materialize_demo` schema that one `DROP SCHEMA` removes. ### Bug Fixes {#v26.45.1-bug-fixes} - Fixed zero-downtime deployment cut-overs stalling for hours on environments with a large catalog audit log, where the incoming `environmentd` re-consolidated its entire catalog snapshot before every attempt to fence the serving instance — about 1.1 s against the largest production catalog's 7.4 million audit entries — and so lost the race against that instance's advancing frontier each time, leaving one cut-over waiting 3 h 11 min over roughly 1,700 attempts; a sync that applies no updates now skips the redundant pass. - Fixed connection poolers losing track of session variables across `DISCARD ALL`, which now reports `ParameterStatus` for every reportable parameter whose value it changed, as `RESET` and PostgreSQL do; with pgbouncer and `server_reset_query_always=1` this had left every client's `application_name` empty. - Fixed hedged reads from object storage staying disabled for the lifetime of any process that started while the object store or its credential service was unavailable, which was observed during a regional AWS STS outage; the hedge connection is now opened in the background with retries, so it arms once the store recovers, and process startup no longer waits on it. -- Fixed `Invalid Parquet file. Corrupt footer` crashes when reading a large object from an S3-compatible object store that does not return a part count on a part request, and added a length check that turns a short read from any store into a retried failure rather than corrupt data downstream. -- Fixed cluster replicas from an earlier generation being left running during a zero-downtime deployment, where continuous DDL could repeatedly restart the read-only `environmentd` before it finished cleaning up orphaned replicas. -- Fixed `environmentd` and `clusterd` aborting when a MySQL connection, including during connection purification and `VALIDATE CONNECTION`, reached a server that switched authentication to MariaDB `parsec`; the client panic is now returned as a connection error. -- Fixed sporadic schema registry TLS failures caused by a stale OpenSSL error left on the worker thread after creating a Kafka client that reads certificates from `ssl.ca.pem`. -- Fixed the Console reporting different cluster utilization on the cluster list, the cluster detail page, and the utilization charts, which now all show the most recent sample from the same view; fixed memory and CPU readings on multi-process replica sizes (`2xlarge` and larger), which were reported per process rather than merged across processes; and fixed a cluster metrics gauge labeled "Heap Utilization" that showed memory and `0 B` on deployments that run without a heap limit. +- Fixed orphaned cluster replicas being left running during a zero-downtime deployment, where continuous DDL could repeatedly restart the read-only `environmentd` before it finished cleaning them up. +- Fixed the Console reporting different cluster utilization on the cluster list, the cluster detail page, and the utilization charts, which now all show the most recent sample from the same view; and fixed memory and CPU readings on multi-process replica sizes, which were reported per process rather than merged across processes. ## v26.44.1 *Released to Materialize Cloud: 2026-09-30*
From 326de40fff062ab8e821448487c458a444869716 Mon Sep 17 00:00:00 2001 From: Valerie Chiang Date: Thu, 8 Oct 2026 15:23:06 -0400 Subject: [PATCH 10/10] releases: shorten v26.45.1 notes and drop low-impact entries Trim each entry to one or two sentences, and drop the mz-debug-freshness, hedged-read and orphaned-replica entries. Co-Authored-By: Claude Opus 5.5 --- doc/user/content/releases/_index.md | 25 +++++++++++-------------- 1 file changed, 11 insertions(+), 14 deletions(-) diff --git a/doc/user/content/releases/_index.md b/doc/user/content/releases/_index.md index fdc63a4a6c86f..306ff46134967 100644 --- a/doc/user/content/releases/_index.md +++ b/doc/user/content/releases/_index.md @@ -37,25 +37,22 @@ Starting with v16.0.0 of the [Materialize Terraform modules](/self-managed-deplo A default install configures no receiver, so alerts notify nobody until you add one. For more information, see [Alerting](/observability/self-managed/alerting/) and [Customize alerting](/observability/self-managed/customize-alerting/). ### Improvements {#v26.45.1-improvements} -- **External dependency monitoring for Self-Managed**: Starting with v15.0.0 of the [Materialize Terraform modules](/self-managed-deployments/installation/#install-using-terraform-modules), new **Materialize Persist (Storage)** and **Materialize Consensus (Metadata)** dashboards show the object storage and metadata database that Materialize depends on, as Materialize experiences them, so you can tell quickly whether a problem is in Materialize or in one of its dependencies. **Infrastructure Cloud Provider** adds what your cloud provider reports about them, once you turn on cloud provider metrics. +- **External dependency monitoring for Self-Managed**: Starting with v15.0.0 of the [Materialize Terraform modules](/self-managed-deployments/installation/#install-using-terraform-modules), new **Materialize Persist (Storage)** and **Materialize Consensus (Metadata)** dashboards show the object storage and metadata database that Materialize depends on, so you can tell quickly whether a problem is in Materialize or in one of its dependencies. - **`sum` and `avg` over `interval`**: `sum(interval)` and `avg(interval)` now work and return `interval`, matching PostgreSQL. -- **Improved compatibility with PostgreSQL ODBC clients**: `expr OPERATOR(pg_catalog.=) expr` and the prefix form `OPERATOR(pg_catalog.-) 1` now parse, so queries psqlODBC routinely generates no longer fail with `Expected operator, found equals sign`; as in PostgreSQL, a function named `operator` must now be quoted. -- **Lower memory for `MIN` and `MAX`**: A materialized view or index computing a single `MIN` or `MAX` over an input that receives updates or deletes no longer keeps an extra copy of its input in memory — for a `MAX` over 100,000 rows in 1,000 groups, the view's arrangements fell from 16.8 MB to 12.8 MB and the first reduction stage from 100,000 records to none under the default bucketing. -- **Lower `SUBSCRIBE` and query latency from introspection logging**: The compute introspection logging dataflow now drains its input in bounded chunks rather than processing a whole interval of events in one uninterruptible call, which on a 4-worker replica serving 1,000 `SUBSCRIBE` timestamps per second took p99 latency for results waiting on the subscribe frontier from 78–86 ms to 9–14 ms and halved the worst per-second index `SELECT` latency. -- **Stricter Kubernetes API server certificate verification in Self-Managed deployments**: The Materialize operator, `environmentd`, and `mz-debug` now verify the Kubernetes API server certificate with rustls rather than OpenSSL, which requires the certificate to carry a subject alternative name matching the address used to reach the API server and rejects a certificate that names the host only in its common name, so clusters with hand-issued API server certificates should confirm their subject alternative names before upgrading; EKS, GKE, AKS, and kind are unaffected. -- **Schema registry and `COPY FROM` server certificates must carry a subject alternative name**: Confluent Schema Registry connections, `COPY FROM` URLs, and the OIDC issuer fetch now reject a server certificate that identifies its host only by common name, so reissue any such certificate with a matching subject alternative name before upgrading; a schema registry server certificate byte-for-byte identical to the one configured as its `SSL CERTIFICATE AUTHORITY` stays trusted and is still matched on its common name when the pinned certificate carries no DNS or IP subject alternative name, but `COPY FROM` and the OIDC issuer fetch have no such exception. -- **Kubernetes events from the Materialize operator**: The operator now publishes Kubernetes events on `Materialize`, `Balancer`, and `Console` resources when it fails to reconcile them, and on each `Materialize` rollout phase, so `kubectl describe` shows why a resource is not progressing; its ClusterRole gains `create` and `patch` on `events.k8s.io` events. +- **Improved compatibility with PostgreSQL ODBC clients**: Queries that psqlODBC generates with `OPERATOR(pg_catalog.=)` syntax now parse instead of failing. +- **Lower memory for `MIN` and `MAX`**: A materialized view or index computing a single `MIN` or `MAX` over an input that receives updates or deletes no longer keeps an extra copy of its input in memory. +- **Lower `SUBSCRIBE` and query latency**: Introspection logging now processes its events in bounded chunks instead of all at once, so it no longer holds up `SUBSCRIBE` results and indexed queries on the same replica. +- **Kubernetes API server certificates need a subject alternative name (Self-Managed)**: The Materialize operator, `environmentd`, and `mz-debug` now reject a Kubernetes API server certificate that names its host only in its common name. EKS, GKE, AKS, and kind are unaffected; if you use hand-issued API server certificates, check them before upgrading. +- **Schema registry and `COPY FROM` server certificates need a subject alternative name**: Confluent Schema Registry connections, `COPY FROM` URLs, and the OIDC issuer fetch now reject a server certificate that names its host only in its common name, so reissue any such certificate with a matching subject alternative name before upgrading. A schema registry certificate that is byte-for-byte identical to the connection's `SSL CERTIFICATE AUTHORITY` is still trusted. +- **Kubernetes events from the Materialize operator**: The operator now publishes Kubernetes events when it fails to reconcile a `Materialize`, `Balancer`, or `Console` resource and at each `Materialize` rollout phase, so `kubectl describe` shows why a resource is not progressing. ### Agent Skills {#v26.45.1-agent-skills} -- **`mz-debug-freshness`**: Two corrections to how the skill reads a replica — its operator cost and skew queries now count each plan node's outermost operators only, instead of summing a region's elapsed time on top of the operators nested inside it, which had overstated joins, reductions, and TopK by 1.5x to 3x; and it now judges replica headroom from `heap_percent`, which counts RAM and swap together, rather than `memory_percent`, which counts RAM only and can sit near 100 while a swapping replica still has room. -- **`mz-demo-data`**: A new skill that stands up continuously-updating, realistic synthetic data inside a running Materialize instance using views over `mz_now()` — no Kafka, no external load generator, and no seed scripts — in a dedicated `materialize_demo` schema that one `DROP SCHEMA` removes. +- **`mz-demo-data`**: A new skill that creates continuously updating synthetic data inside Materialize using views over `mz_now()`, with no Kafka or external load generator, in a `materialize_demo` schema that one `DROP SCHEMA` removes. ### Bug Fixes {#v26.45.1-bug-fixes} -- Fixed zero-downtime deployment cut-overs stalling for hours on environments with a large catalog audit log, where the incoming `environmentd` re-consolidated its entire catalog snapshot before every attempt to fence the serving instance — about 1.1 s against the largest production catalog's 7.4 million audit entries — and so lost the race against that instance's advancing frontier each time, leaving one cut-over waiting 3 h 11 min over roughly 1,700 attempts; a sync that applies no updates now skips the redundant pass. -- Fixed connection poolers losing track of session variables across `DISCARD ALL`, which now reports `ParameterStatus` for every reportable parameter whose value it changed, as `RESET` and PostgreSQL do; with pgbouncer and `server_reset_query_always=1` this had left every client's `application_name` empty. -- Fixed hedged reads from object storage staying disabled for the lifetime of any process that started while the object store or its credential service was unavailable, which was observed during a regional AWS STS outage; the hedge connection is now opened in the background with retries, so it arms once the store recovers, and process startup no longer waits on it. -- Fixed orphaned cluster replicas being left running during a zero-downtime deployment, where continuous DDL could repeatedly restart the read-only `environmentd` before it finished cleaning them up. -- Fixed the Console reporting different cluster utilization on the cluster list, the cluster detail page, and the utilization charts, which now all show the most recent sample from the same view; and fixed memory and CPU readings on multi-process replica sizes, which were reported per process rather than merged across processes. +- Fixed zero-downtime deployment cut-overs that could stall for hours on environments with a large catalog audit log. +- Fixed `DISCARD ALL` not reporting the parameters it resets, which caused connection poolers such as pgbouncer to lose track of values like `application_name`. +- Fixed the Console showing different cluster utilization on different pages, and reporting memory and CPU per process rather than combined for multi-process replicas. ## v26.44.1 *Released to Materialize Cloud: 2026-09-30*