From e8051541a985f8301233718456efabe8a0efdd02 Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 9 Oct 2026 07:23:00 +0000 Subject: [PATCH 1/8] v26.46.0 release notes (rc.1) Adds the `## v26.46.0` section to `doc/user/content/releases/_index.md` and the operator compatibility row for v26.46, from the rc.1 snapshot. Dates are provisional (Cloud 2026-10-15, Self-Managed 2026-10-16) and are set for real by the final snapshot. --- doc/user/content/releases/_index.md | 28 +++++++++++++++++++ .../self_managed_operator_compatibility.yml | 5 ++++ 2 files changed, 33 insertions(+) diff --git a/doc/user/content/releases/_index.md b/doc/user/content/releases/_index.md index 42f7f26d35e6a..1963b32015fa3 100644 --- a/doc/user/content/releases/_index.md +++ b/doc/user/content/releases/_index.md @@ -20,6 +20,34 @@ 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.46.0 +*Released to Materialize Cloud: 2026-10-15*
+*Released to Materialize Self-Managed: 2026-10-16*
+ +### Metric Sinks {#v26.46-metric-sinks} +`CREATE METRIC SINK`, `DROP METRIC SINK`, and `SHOW METRIC SINKS` are now available without setting a feature flag. A metric sink exports a relation that supplies `metric_name`, `metric_type`, `labels`, `value`, and `help` columns as Prometheus metrics under a name you choose, and every cluster now also renders two built-in curated sinks covering arrangement sizes and dataflow errors. Cluster-level health and your own SQL-defined measurements reach your existing Prometheus monitoring without a separate exporter. + +### Improvements {#v26.46-improvements} +- **Replication-factor changes during a cluster reconfiguration**: `ALTER CLUSTER ... SET (REPLICATION FACTOR ...)` is now accepted while a graceful reconfiguration is in flight, preserving the dimensions and the deadline you did not name, so you can scale a stuck reconfiguration down to zero or cancel it by restoring the original configuration instead of waiting it out. +- **Zero-downtime deployment readiness follows replica hydration**: A zero-downtime deployment now asks each replica how long it has been hydrated instead of tracking cluster status itself, so a read-only `environmentd` restart that picks up DDL no longer resets the stability period, drop-only DDL restarts the read-only generation so it can release obsolete replicas and read holds, and a replica that stays online but never hydrates holds the cut-over until `with_0dt_deployment_max_wait` passes or the deployment is promoted with skip-catchup. +- **Constraint exclusion for MySQL source tables**: `CREATE TABLE ... FROM SOURCE` now accepts `EXCLUDE CONSTRAINTS` and `EXCLUDE ALL CONSTRAINTS` against MySQL sources as it already did for Postgres, dropping the named primary key and unique constraints — and, with `EXCLUDE ALL CONSTRAINTS`, the nullability constraints too — so that an upstream constraint change does not stall the table. +- **Read-then-write statements no longer take a table write lock**: `DELETE`, `UPDATE`, and read-then-write `INSERT` now sequence through optimistic concurrency control by default, detecting intervening writes through timestamp conflicts rather than holding a per-table write lock for the span between the read and the write. +- **Lower memory when ingesting wide schemas**: Sources with wide or deeply nested schemas now need less memory to write their data, because each column's encoding buffer starts empty and grows on demand instead of preallocating 1,024 slots. +- **Kafka sink message attribution** (private preview): Kafka sinks can now attach a `materialize-sink-id` header carrying the sink's ID to every message they produce, so a consumer of a topic that several sinks write to can tell which sink produced each message. +- **Kafka broker addresses are checked against private IP ranges**: In Materialize Cloud, a Kafka connection that reaches its brokers directly, rather than through PrivateLink or an SSH tunnel, now fails with "Broker address resolved to a private IP" unless every address the broker resolves to is a global address — at bootstrap, from cluster metadata, and on every re-resolution — while self-managed deployments are unaffected. +- **Network policies are off by default in self-managed deployments**: The operator Helm chart now starts `environmentd` with `CREATE NETWORK POLICY` and `ALTER NETWORK POLICY` disabled, because network policies match on the client IP and self-managed access paths such as port-forwards present a proxy address instead; set `operator.args.enableDatabaseNetworkPolicies` to turn them back on. +- **Account pages are reachable before an environment is ready**: The Console now renders the environment-not-ready flow inside the standard layout, so an organization still waiting on its first environment can reach App Passwords, License, and Usage & Billing from the navigation. +- **Lower `mz_catalog_server` load from open cluster pages**: Cluster detail pages now resolve blue/green lineage with a peek refreshed every five minutes and subscribe to utilization by literal cluster ID, so each open page performs index lookups on `mz_catalog_server` instead of a dataflow that fully scans the utilization and lineage indexes. + +### Bug Fixes {#v26.46-bug-fixes} +- Fixed casts from `"char"` to numbers and other non-string types, which panicked the optimizer during constant folding or crashed the replica running an operator over a `"char"` column; `"char"` to `int4` now yields the byte value, and every other target goes through the text representation. +- Fixed `EXPLAIN ANALYZE CPU` and `EXPLAIN ANALYZE CLUSTER CPU` counting operators nested inside regions more than once, which reported 1.5x to 3x the real CPU time for joins, reduces, and `TopK` — on a test rig a hierarchical `MAX` reported 217 s against an actual 74 s. +- Fixed `offset_committed` in `mz_source_statistics` reporting the progress of a source's slowest export for every one of its exports, so a subsource or table that is still snapshotting no longer inflates the ingestion lag reported for the others. +- Fixed replica-scoped configuration overrides being dropped when a compute replica reconnected after its controller connection timed out, which left that replica running without its overrides for the rest of its life while `mz_replica_system_parameters` still listed them. +- Fixed `COPY FROM` a URL decoding the response body into the target table when the server answered with a 4xx or 5xx status, which now fails with `server returned HTTP `. +- Fixed the MCP server rejecting a `tools/call` request that omits the optional `arguments` key with a bare 422 instead of running the tool. +- Fixed the MCP server answering an unknown method that carries `params` with a bare 422 instead of a JSON-RPC "method not found" error. + ## v26.44.1 *Released to Materialize Cloud: 2026-10-01*
*Released to Materialize Self-Managed: 2026-10-02*
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 1651773e87c32..e8bff370f4b30 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.46 + orchestratord version: v26.46 + environmentd version: v26.46 + Release date: "2026-10-16" + Notes: "See [v26.46 release notes](/releases/#v26460)" - Materialize Operator: v26.44.1 orchestratord version: v26.44.1 environmentd version: v26.44.1 From 512e30e5b839d4c960195769e8fcf5ad2dda9df7 Mon Sep 17 00:00:00 2001 From: Valerie Chiang Date: Fri, 9 Oct 2026 10:18:13 -0400 Subject: [PATCH 2/8] doc: give Kafka sink message attribution its own release notes section Moves the materialize-sink-id header entry out of Improvements into a private-preview section, matching how SCIM role mapping was announced in v26.34, and links to the CREATE SINK Headers docs. Co-Authored-By: Claude Opus 5.5 --- doc/user/content/releases/_index.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/doc/user/content/releases/_index.md b/doc/user/content/releases/_index.md index 1963b32015fa3..24588da8f01fe 100644 --- a/doc/user/content/releases/_index.md +++ b/doc/user/content/releases/_index.md @@ -27,13 +27,18 @@ both Cloud and Self-Managed. See [Release schedule](/releases/schedule) for deta ### Metric Sinks {#v26.46-metric-sinks} `CREATE METRIC SINK`, `DROP METRIC SINK`, and `SHOW METRIC SINKS` are now available without setting a feature flag. A metric sink exports a relation that supplies `metric_name`, `metric_type`, `labels`, `value`, and `help` columns as Prometheus metrics under a name you choose, and every cluster now also renders two built-in curated sinks covering arrangement sizes and dataflow errors. Cluster-level health and your own SQL-defined measurements reach your existing Prometheus monitoring without a separate exporter. +### Kafka sink message attribution {#v26.46-kafka-sink-id-header} + +{{< private-preview />}} + +Kafka sinks can now attach a `materialize-sink-id` header carrying the sink's ID to every message they produce, so a consumer of a topic that several sinks write to can tell which sink produced each message. For more information, see [`CREATE SINK`: Headers](/sql/create-sink/kafka/#headers). + ### Improvements {#v26.46-improvements} - **Replication-factor changes during a cluster reconfiguration**: `ALTER CLUSTER ... SET (REPLICATION FACTOR ...)` is now accepted while a graceful reconfiguration is in flight, preserving the dimensions and the deadline you did not name, so you can scale a stuck reconfiguration down to zero or cancel it by restoring the original configuration instead of waiting it out. - **Zero-downtime deployment readiness follows replica hydration**: A zero-downtime deployment now asks each replica how long it has been hydrated instead of tracking cluster status itself, so a read-only `environmentd` restart that picks up DDL no longer resets the stability period, drop-only DDL restarts the read-only generation so it can release obsolete replicas and read holds, and a replica that stays online but never hydrates holds the cut-over until `with_0dt_deployment_max_wait` passes or the deployment is promoted with skip-catchup. - **Constraint exclusion for MySQL source tables**: `CREATE TABLE ... FROM SOURCE` now accepts `EXCLUDE CONSTRAINTS` and `EXCLUDE ALL CONSTRAINTS` against MySQL sources as it already did for Postgres, dropping the named primary key and unique constraints — and, with `EXCLUDE ALL CONSTRAINTS`, the nullability constraints too — so that an upstream constraint change does not stall the table. - **Read-then-write statements no longer take a table write lock**: `DELETE`, `UPDATE`, and read-then-write `INSERT` now sequence through optimistic concurrency control by default, detecting intervening writes through timestamp conflicts rather than holding a per-table write lock for the span between the read and the write. - **Lower memory when ingesting wide schemas**: Sources with wide or deeply nested schemas now need less memory to write their data, because each column's encoding buffer starts empty and grows on demand instead of preallocating 1,024 slots. -- **Kafka sink message attribution** (private preview): Kafka sinks can now attach a `materialize-sink-id` header carrying the sink's ID to every message they produce, so a consumer of a topic that several sinks write to can tell which sink produced each message. - **Kafka broker addresses are checked against private IP ranges**: In Materialize Cloud, a Kafka connection that reaches its brokers directly, rather than through PrivateLink or an SSH tunnel, now fails with "Broker address resolved to a private IP" unless every address the broker resolves to is a global address — at bootstrap, from cluster metadata, and on every re-resolution — while self-managed deployments are unaffected. - **Network policies are off by default in self-managed deployments**: The operator Helm chart now starts `environmentd` with `CREATE NETWORK POLICY` and `ALTER NETWORK POLICY` disabled, because network policies match on the client IP and self-managed access paths such as port-forwards present a proxy address instead; set `operator.args.enableDatabaseNetworkPolicies` to turn them back on. - **Account pages are reachable before an environment is ready**: The Console now renders the environment-not-ready flow inside the standard layout, so an organization still waiting on its first environment can reach App Passwords, License, and Usage & Billing from the navigation. From 4911e1b4258028627709b5725904d09848eef438 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 14 Oct 2026 19:00:33 +0000 Subject: [PATCH 3/8] v26.46.0 release notes (final) The final snapshot of this train publishes no new entries: comparing v26.46.0-rc.1...v26.46.0 is ahead_by 1 and that commit is the version bump, so nothing was cherry-picked onto the release branch after rc.1. The five agent-skills PRs in the window are four automated mz-docs regenerations plus one prose clarification, all omitted. The real dates - Cloud 2026-10-15, Self-Managed 2026-10-16 - are identical to the provisional pair rc.1 estimated, so the two date lines in _index.md and the Release date in the operator-compatibility YAML already carry them and need no edit. This commit records the snapshot as applied. One item for the release owner: Metric Sinks, the release's headline feature, still has no user-facing documentation at the final tag - doc/user has no page for CREATE METRIC SINK, DROP METRIC SINK, or SHOW METRIC SINKS. Either a docs page lands with the release, or the section is held for the release that ships its documentation. From 7a8e1f5593dce5919f902c43084f00b307ab0ecb Mon Sep 17 00:00:00 2001 From: Valerie Chiang Date: Fri, 16 Oct 2026 11:34:53 -0400 Subject: [PATCH 4/8] releases: give MySQL constraint exclusion its own v26.46.0 section Co-Authored-By: Claude Opus 5.5 --- doc/user/content/releases/_index.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/doc/user/content/releases/_index.md b/doc/user/content/releases/_index.md index 6f2f5ada862f0..09110a5d84290 100644 --- a/doc/user/content/releases/_index.md +++ b/doc/user/content/releases/_index.md @@ -33,10 +33,20 @@ both Cloud and Self-Managed. See [Release schedule](/releases/schedule) for deta Kafka sinks can now attach a `materialize-sink-id` header carrying the sink's ID to every message they produce, so a consumer of a topic that several sinks write to can tell which sink produced each message. For more information, see [`CREATE SINK`: Headers](/sql/create-sink/kafka/#headers). +### Exclude upstream constraints from MySQL source tables {#v26.46-mysql-exclude-constraints} + +{{< public-preview />}} + +`CREATE TABLE ... FROM SOURCE` now accepts `EXCLUDE CONSTRAINTS` and `EXCLUDE ALL CONSTRAINTS` for MySQL sources, as it already did for PostgreSQL sources. This lets you drop a `PRIMARY KEY`, `UNIQUE`, or `NOT NULL` constraint upstream without stalling ingestion: + +- `EXCLUDE CONSTRAINTS` excludes the `PRIMARY KEY` and `UNIQUE` constraints you name. +- `EXCLUDE ALL CONSTRAINTS` excludes every constraint, including `NOT NULL`, so the table has no keys and every column is nullable. + +For more information, see [Handle upstream constraint drop](/ingest-data/mysql/source-versioning/#handle-upstream-constraint-drop). + ### Improvements {#v26.46-improvements} - **Replication-factor changes during a cluster reconfiguration**: `ALTER CLUSTER ... SET (REPLICATION FACTOR ...)` is now accepted while a graceful reconfiguration is in flight, preserving the dimensions and the deadline you did not name, so you can scale a stuck reconfiguration down to zero or cancel it by restoring the original configuration instead of waiting it out. - **Zero-downtime deployment readiness follows replica hydration**: A zero-downtime deployment now asks each replica how long it has been hydrated instead of tracking cluster status itself, so a read-only `environmentd` restart that picks up DDL no longer resets the stability period, drop-only DDL restarts the read-only generation so it can release obsolete replicas and read holds, and a replica that stays online but never hydrates holds the cut-over until `with_0dt_deployment_max_wait` passes or the deployment is promoted with skip-catchup. -- **Constraint exclusion for MySQL source tables**: `CREATE TABLE ... FROM SOURCE` now accepts `EXCLUDE CONSTRAINTS` and `EXCLUDE ALL CONSTRAINTS` against MySQL sources as it already did for Postgres, dropping the named primary key and unique constraints — and, with `EXCLUDE ALL CONSTRAINTS`, the nullability constraints too — so that an upstream constraint change does not stall the table. - **Read-then-write statements no longer take a table write lock**: `DELETE`, `UPDATE`, and read-then-write `INSERT` now sequence through optimistic concurrency control by default, detecting intervening writes through timestamp conflicts rather than holding a per-table write lock for the span between the read and the write. - **Lower memory when ingesting wide schemas**: Sources with wide or deeply nested schemas now need less memory to write their data, because each column's encoding buffer starts empty and grows on demand instead of preallocating 1,024 slots. - **Kafka broker addresses are checked against private IP ranges**: In Materialize Cloud, a Kafka connection that reaches its brokers directly, rather than through PrivateLink or an SSH tunnel, now fails with "Broker address resolved to a private IP" unless every address the broker resolves to is a global address — at bootstrap, from cluster metadata, and on every re-resolution — while self-managed deployments are unaffected. From c7511fb92b736499314f6b08ca5f844be4b86f0c Mon Sep 17 00:00:00 2001 From: Pranshu Maheshwari Date: Fri, 16 Oct 2026 12:27:19 -0400 Subject: [PATCH 5/8] Remove Metric Sinks and Kafka sink attribution details Removed sections on Metric Sinks and Kafka sink message attribution from the release notes for version 26.46.0. --- doc/user/content/releases/_index.md | 9 --------- 1 file changed, 9 deletions(-) diff --git a/doc/user/content/releases/_index.md b/doc/user/content/releases/_index.md index 09110a5d84290..5b7ffd9c7f0eb 100644 --- a/doc/user/content/releases/_index.md +++ b/doc/user/content/releases/_index.md @@ -24,15 +24,6 @@ both Cloud and Self-Managed. See [Release schedule](/releases/schedule) for deta *Released to Materialize Cloud: 2026-10-15*
*Released to Materialize Self-Managed: 2026-10-16*
-### Metric Sinks {#v26.46-metric-sinks} -`CREATE METRIC SINK`, `DROP METRIC SINK`, and `SHOW METRIC SINKS` are now available without setting a feature flag. A metric sink exports a relation that supplies `metric_name`, `metric_type`, `labels`, `value`, and `help` columns as Prometheus metrics under a name you choose, and every cluster now also renders two built-in curated sinks covering arrangement sizes and dataflow errors. Cluster-level health and your own SQL-defined measurements reach your existing Prometheus monitoring without a separate exporter. - -### Kafka sink message attribution {#v26.46-kafka-sink-id-header} - -{{< private-preview />}} - -Kafka sinks can now attach a `materialize-sink-id` header carrying the sink's ID to every message they produce, so a consumer of a topic that several sinks write to can tell which sink produced each message. For more information, see [`CREATE SINK`: Headers](/sql/create-sink/kafka/#headers). - ### Exclude upstream constraints from MySQL source tables {#v26.46-mysql-exclude-constraints} {{< public-preview />}} From b270b304d2cb943f2d2022419fe37d584c6661a1 Mon Sep 17 00:00:00 2001 From: Valerie Chiang Date: Fri, 16 Oct 2026 13:22:19 -0400 Subject: [PATCH 6/8] releases: restore Kafka sink message attribution in v26.46.0 Co-Authored-By: Claude Opus 5.5 --- doc/user/content/releases/_index.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/doc/user/content/releases/_index.md b/doc/user/content/releases/_index.md index 5b7ffd9c7f0eb..8933eb15be670 100644 --- a/doc/user/content/releases/_index.md +++ b/doc/user/content/releases/_index.md @@ -24,6 +24,12 @@ both Cloud and Self-Managed. See [Release schedule](/releases/schedule) for deta *Released to Materialize Cloud: 2026-10-15*
*Released to Materialize Self-Managed: 2026-10-16*
+### Kafka sink message attribution {#v26.46-kafka-sink-id-header} + +{{< private-preview />}} + +Kafka sinks can now attach a `materialize-sink-id` header carrying the sink's ID to every message they produce, so a consumer of a topic that several sinks write to can tell which sink produced each message. For more information, see [`CREATE SINK`: Headers](/sql/create-sink/kafka/#headers). + ### Exclude upstream constraints from MySQL source tables {#v26.46-mysql-exclude-constraints} {{< public-preview />}} From e2a74387fad1b4c304377339235a3904ba989173 Mon Sep 17 00:00:00 2001 From: Valerie Chiang Date: Fri, 16 Oct 2026 13:38:27 -0400 Subject: [PATCH 7/8] releases: correct and trim v26.46.0 entries Cut the Console account-pages entry (Cloud-only, live in Cloud before the release) and the replica-scoped override fix (internal flags only). Drop "by default" from read-then-write (the flag was removed), narrow the network policy entry to create/alter, note that Kafka sources on private brokers stall on reconnect, and trim internal detail elsewhere. Co-Authored-By: Claude Opus 5.5 --- doc/user/content/releases/_index.md | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/doc/user/content/releases/_index.md b/doc/user/content/releases/_index.md index 8933eb15be670..683d02488ac79 100644 --- a/doc/user/content/releases/_index.md +++ b/doc/user/content/releases/_index.md @@ -43,22 +43,20 @@ For more information, see [Handle upstream constraint drop](/ingest-data/mysql/s ### Improvements {#v26.46-improvements} - **Replication-factor changes during a cluster reconfiguration**: `ALTER CLUSTER ... SET (REPLICATION FACTOR ...)` is now accepted while a graceful reconfiguration is in flight, preserving the dimensions and the deadline you did not name, so you can scale a stuck reconfiguration down to zero or cancel it by restoring the original configuration instead of waiting it out. -- **Zero-downtime deployment readiness follows replica hydration**: A zero-downtime deployment now asks each replica how long it has been hydrated instead of tracking cluster status itself, so a read-only `environmentd` restart that picks up DDL no longer resets the stability period, drop-only DDL restarts the read-only generation so it can release obsolete replicas and read holds, and a replica that stays online but never hydrates holds the cut-over until `with_0dt_deployment_max_wait` passes or the deployment is promoted with skip-catchup. -- **Read-then-write statements no longer take a table write lock**: `DELETE`, `UPDATE`, and read-then-write `INSERT` now sequence through optimistic concurrency control by default, detecting intervening writes through timestamp conflicts rather than holding a per-table write lock for the span between the read and the write. -- **Lower memory when ingesting wide schemas**: Sources with wide or deeply nested schemas now need less memory to write their data, because each column's encoding buffer starts empty and grows on demand instead of preallocating 1,024 slots. -- **Kafka broker addresses are checked against private IP ranges**: In Materialize Cloud, a Kafka connection that reaches its brokers directly, rather than through PrivateLink or an SSH tunnel, now fails with "Broker address resolved to a private IP" unless every address the broker resolves to is a global address — at bootstrap, from cluster metadata, and on every re-resolution — while self-managed deployments are unaffected. -- **Network policies are off by default in self-managed deployments**: The operator Helm chart now starts `environmentd` with `CREATE NETWORK POLICY` and `ALTER NETWORK POLICY` disabled, because network policies match on the client IP and self-managed access paths such as port-forwards present a proxy address instead; set `operator.args.enableDatabaseNetworkPolicies` to turn them back on. -- **Account pages are reachable before an environment is ready**: The Console now renders the environment-not-ready flow inside the standard layout, so an organization still waiting on its first environment can reach App Passwords, License, and Usage & Billing from the navigation. -- **Lower `mz_catalog_server` load from open cluster pages**: Cluster detail pages now resolve blue/green lineage with a peek refreshed every five minutes and subscribe to utilization by literal cluster ID, so each open page performs index lookups on `mz_catalog_server` instead of a dataflow that fully scans the utilization and lineage indexes. +- **Zero-downtime deployment readiness follows replica hydration**: Zero-downtime deployments no longer restart their stability period when the new deployment restarts to pick up DDL changes, and now wait for every replica of a cluster to hydrate before cutting over. +- **Read-then-write statements no longer take a table write lock**: `DELETE`, `UPDATE`, and `INSERT` statements that read before writing no longer hold a per-table write lock between the read and the write. +- **Lower memory when ingesting wide schemas**: Sources with wide schemas now need less memory to write their data. +- **Kafka broker addresses are checked against private IP ranges**: In Materialize Cloud, Kafka connections that reach brokers directly (not through PrivateLink or an SSH tunnel) now fail with `Broker address resolved to a private IP` if a broker resolves to a private address. Existing sources and sinks using such brokers stall the next time they reconnect. +- **Creating and altering network policies is disabled by default in Self-Managed**: The operator Helm chart now disables `CREATE NETWORK POLICY` and `ALTER NETWORK POLICY`, because self-managed access paths such as port-forwards don't preserve the client IP. Existing policies are still enforced. To manage network policies, set `operator.args.enableDatabaseNetworkPolicies: true`. +- **Lower `mz_catalog_server` load from open cluster pages**: Open cluster detail pages in the Console put much less load on the `mz_catalog_server` cluster. ### Bug Fixes {#v26.46-bug-fixes} - Fixed casts from `"char"` to numbers and other non-string types, which panicked the optimizer during constant folding or crashed the replica running an operator over a `"char"` column; `"char"` to `int4` now yields the byte value, and every other target goes through the text representation. -- Fixed `EXPLAIN ANALYZE CPU` and `EXPLAIN ANALYZE CLUSTER CPU` counting operators nested inside regions more than once, which reported 1.5x to 3x the real CPU time for joins, reduces, and `TopK` — on a test rig a hierarchical `MAX` reported 217 s against an actual 74 s. +- Fixed `EXPLAIN ANALYZE CPU` and `EXPLAIN ANALYZE CLUSTER CPU` counting operators nested inside regions more than once, which reported 1.5x to 3x the real CPU time for joins, reduces, and `TopK`. - Fixed `offset_committed` in `mz_source_statistics` reporting the progress of a source's slowest export for every one of its exports, so a subsource or table that is still snapshotting no longer inflates the ingestion lag reported for the others. -- Fixed replica-scoped configuration overrides being dropped when a compute replica reconnected after its controller connection timed out, which left that replica running without its overrides for the rest of its life while `mz_replica_system_parameters` still listed them. - Fixed `COPY FROM` a URL decoding the response body into the target table when the server answered with a 4xx or 5xx status, which now fails with `server returned HTTP `. -- Fixed the MCP server rejecting a `tools/call` request that omits the optional `arguments` key with a bare 422 instead of running the tool. -- Fixed the MCP server answering an unknown method that carries `params` with a bare 422 instead of a JSON-RPC "method not found" error. +- Fixed the MCP server returning an HTTP 422 error for a `tools/call` request without the optional `arguments` field. +- Fixed the MCP server returning an HTTP 422 error, rather than a JSON-RPC "method not found" error, for unsupported methods that include `params`. ## v26.45.1 *Released to Materialize Cloud: 2026-10-08*
From f031adde7979ebf1a952e2066dacd367c4447fbe Mon Sep 17 00:00:00 2001 From: Pranshu Maheshwari Date: Fri, 16 Oct 2026 13:41:47 -0400 Subject: [PATCH 8/8] releases: add v26.46.0 advisory for Self-Managed upsert sources Advises Self-Managed deployments with upsert sources to hold off on upgrading to v26.46.0 because of a potential performance regression, following the advisory format used for the v26.30.1 MySQL YEAR change. Co-Authored-By: Claude Opus 5.5 (1M context) --- doc/user/content/releases/_index.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/doc/user/content/releases/_index.md b/doc/user/content/releases/_index.md index 683d02488ac79..a3e410447cd0a 100644 --- a/doc/user/content/releases/_index.md +++ b/doc/user/content/releases/_index.md @@ -41,6 +41,12 @@ Kafka sinks can now attach a `materialize-sink-id` header carrying the sink's ID For more information, see [Handle upstream constraint drop](/ingest-data/mysql/source-versioning/#handle-upstream-constraint-drop). +### Advisory {#v26.46-advisory} + +- **Self-Managed: Potential performance regression for upsert sources**: This release may regress the performance of [upsert sources](/ingest-data/#upsert-sources), such as Kafka sources that use `ENVELOPE UPSERT`, in Materialize Self-Managed deployments. + + **Upgrade impact**: If you run Materialize Self-Managed with upsert sources, hold off on upgrading to v26.46.0. Self-Managed deployments without upsert sources require no action. + ### Improvements {#v26.46-improvements} - **Replication-factor changes during a cluster reconfiguration**: `ALTER CLUSTER ... SET (REPLICATION FACTOR ...)` is now accepted while a graceful reconfiguration is in flight, preserving the dimensions and the deadline you did not name, so you can scale a stuck reconfiguration down to zero or cancel it by restoring the original configuration instead of waiting it out. - **Zero-downtime deployment readiness follows replica hydration**: Zero-downtime deployments no longer restart their stability period when the new deployment restarts to pick up DDL changes, and now wait for every replica of a cluster to hydrate before cutting over.