iframe-proxy

novikd · 2026-05-15T14:51:54Z

Motivation

Two related shapes of LOGICAL_ERROR: Reading from materialized CTE 'X' before it has been materialized triggered by enable_materialized_cte.

Issue #101940:

WITH
    ct AS MATERIALIZED (SELECT c FROM t LIMIT 10),
    rs AS MATERIALIZED (SELECT * FROM t WHERE c IN (SELECT c FROM ct))
SELECT count()
FROM rs AS a ANY LEFT JOIN rs AS b USING c
SETTINGS enable_materialized_cte = 1;

Issue #102320:

WITH a AS MATERIALIZED (SELECT number AS id FROM numbers(100))
SELECT id FROM a
WHERE id IN (
    SELECT id FROM test
    WHERE id IN (SELECT id FROM a GROUP BY id)
    GROUP BY id
)
GROUP BY id;

EXPLAIN on either query also threw — the bug fires during plan
optimization, not just at execution time.

Root cause

The Planner installs two layers of DelayedMaterializingCTEsStep:

Outer steps at the top of the main plan, one per CTE dependency level,
added by addBuildSubqueriesForMaterializedCTEsIfNeeded so the materialized
CTEs run before the main pipeline at runtime.
Safety-net steps inside every IN-subquery's plan, planted by
forceMaterializeCTE so the synchronous inplace path
(FutureSetFromSubquery::buildSetInplace / buildOrderedSetInplace,
reached via KeyCondition::tryPrepareSetIndexForIn or
VirtualColumnUtils::buildSetsForDAG) can materialize a referenced CTE
during plan optimization.

makePlansForCTEs did the atomic claim, the optimize call, and the
std::move of materialized_cte->plan in one step, and
resolveMaterializingCTEs ran before addStepsToBuildSets. So in both bug
shapes the outer step claimed the CTE and moved its plan out before the
inner safety-net inside the inplace pipeline could win the race —
the safety-net pass-throughs read an empty StorageMemory.

Fix

Three coordinated changes:

Split resolveMaterializingCTEs into two traversals. Pass 1
(DelayedMaterializingCTEsStep::optimizePlans) just optimizes each CTE's
pre-built plan; pass 2 (the existing addPlansForMaterializingCTEs walk)
claims and attaches. makePlansForCTEs no longer optimizes, only claims
and std::moves. With this alone, the failing query from SEGV / LOGICAL_ERROR when materialized CTE is used in IN subquery of another materialized CTE referenced in a join #101940 is
fixed because the safety-net inside rs.plan->optimize claims ct
during pass 1, before main's pass 2 attempts the outer claim.
Run addStepsToBuildSets before resolveMaterializingCTEs in
QueryPlan::optimize. When the inplace path fires from
addStepsToBuildSets on the main plan (LOGICAL_ERROR with materialized CTE #102320's shape, where the IN
target is a MergeTree column and the PK pruning fires during the
recursive outer_IN.plan->optimize), the safety-net inside the nested
IN-subquery is now reached before the outer claim runs, again winning
the race.
Strip safety-net DelayedMaterializingCTEsStep chains from set plans
in DelayedCreatingSetsStep::makePlansForSets. When a set plan is
being attached for runtime construction (vs synchronous inplace
execution), its safety-nets are redundant — at runtime the outer
MaterializingCTEsStep materializes the CTE before the
CreatingSetsStep's pipeline runs. Stripping the whole stacked chain
prevents the recursive plan->optimize from claiming the CTE in the
wrong scope when the safety-net chain has multiple levels (one per
transitive CTE dependency). The strip handles CreatingSetStep wrapping
the chain (added by FutureSetFromSubquery::build).

Test plan

04227_materialized_cte_reused_with_in_subquery.sql covers SEGV / LOGICAL_ERROR when materialized CTE is used in IN subquery of another materialized CTE referenced in a join #101940 in
ANY-LEFT-JOIN-on-PK, cross-join, non-PK IN (VirtualColumnUtils path),
and EXPLAIN.
04228_materialized_cte_nested_in_subquery_pk.sql covers LOGICAL_ERROR with materialized CTE #102320 (CTE
referenced through a PK-pruned nested IN).
The existing materialized-CTE suite passes locally (16 tests:
0380*/0392*/0400*/04036_…distributed_race /
04041_…parallel_replicas / etc.).
04041_materialized_cte_parallel_replicas.reference is updated: with
the new traversal timing, mergeExpressions now merges two adjacent
ExpressionSteps in the CTE's local Union branch into one. Functional
results unchanged.

Changelog category (leave one):

Critical Bug Fix (crash, data loss, RBAC)

Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):

Fixed two LOGICAL_ERROR: Reading from materialized CTE 'X' before it has been materialized shapes thrown by queries with enable_materialized_cte: (1) a reused materialized CTE filtered by IN (subquery) over another materialized CTE, and (2) a materialized CTE referenced both directly and inside a WHERE ... IN (...) filter that hits a MergeTree primary key through a nested IN-subquery. EXPLAIN on the same queries was affected too because the bugs fired during plan optimization. Closes #101940, closes #102320.

Documentation entry for user-facing changes

Documentation is written (mandatory for new features)

Version info

Merged into: 26.6.1.454

The optimization step is moved one level up, into a dedicated first traversal of resolveMaterializingCTEs introduced in the next commit. This lets the recursive buildSetInplace / buildOrderedSetInplace path win the inner safety-net DelayedMaterializingCTEsStep's claim before the outer step attempts its own claim. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The first traversal optimizes every materialized CTE's pre-built plan and reports whether any DelayedMaterializingCTEsStep exists in the tree. The second traversal -- skipped entirely when the first saw none -- replaces DelayedMaterializingCTEsStep nodes with MaterializingCTEsStep, attaching plans for any CTEs not already claimed inplace. Why this fixes the LOGICAL_ERROR -------------------------------- Today makePlansForCTEs did three things atomically: it exchange'd is_materialization_planned, it called materialized_cte->plan->optimize, and it std::moved the plan into the synthesized MaterializingCTEsStep. The outer DelayedMaterializingCTEsStep[ct] in the main plan won the exchange before descending into [rs]; by the time rs.plan->optimize fired buildSetInplace via KeyCondition or VirtualColumnUtils, the inner safety-net DelayedMaterializingCTEsStep inside the IN-subquery's plan found ct.is_materialization_planned already true and degraded to a pass-through. The synchronously executed pipeline read ct.storage with is_built == false and threw. With two traversals, the optimize calls happen first across the entire tree, so the recursive buildSetInplace path gets to run makePlansForCTEs on the inner safety-net step before the outer step's claim is attempted. The outer step then sees the CTE already claimed and degrades to a harmless pass-through. For queries with no materialized CTEs at all (the common case), the first traversal walks the tree without doing any work, reports no DelayedMaterializingCTEsStep, and returns -- keeping the total work at one walk just like before. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…er CTE Covers the LOGICAL_ERROR path that fired when the outer DelayedMaterializingCTEsStep claimed the inner CTE before buildSetInplace had a chance to materialize it synchronously for primary-key / virtual-column analysis. Three query shapes: ANY LEFT JOIN on PK, cross-join on PK, ANY LEFT JOIN with the IN filter on a non-PK column (exercising the VirtualColumnUtils path). EXPLAIN is also checked because the bug fired during plan optimization -- the test only asserts that EXPLAIN produced at least one row so the reference file is not pinned to a specific plan shape. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

… Expressions The two-traversal refactor in resolveMaterializingCTEs shifts the timing of `materialized_cte->plan->optimize` such that mergeExpressions now successfully collapses two adjacent ExpressionSteps in the materialized CTE's local Union branch (Project names + Change column names | Projection + Change column names to column identifiers). Functional results are unchanged (count() = 3 twice). The merged ExpressionStep performs identical work in a single transform. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

clickhouse-gh · 2026-05-15T14:52:31Z

Workflow [PR], commit [46bf468]

Summary: ✅

Performance Comparison: Performance dashboard

AI Review

Summary

This PR rewires materialized CTE planning so IN-subquery set construction cannot read a CTE before its writer has run. The core SELECT path is much better covered now, but I found two remaining regressions in surrounding pipeline/set-plan surfaces that should be fixed before merge.

PR Metadata

💡 Changelog category should be Bug Fix (user-visible misbehavior in an official stable release), not Critical Bug Fix, because the release-build user impact is a LOGICAL_ERROR exception rather than data loss/RBAC.
💡 The Changelog entry is specific, but issue-closing text should not be part of the changelog entry. Move these to standalone PR-description lines:
Closes: https://github.com/ClickHouse/ClickHouse/issues/101940
Closes: https://github.com/ClickHouse/ClickHouse/issues/102320

Findings

⚠️ Majors

[src/Processors/QueryPlan/CreatingSetsStep.cpp:244] removeAllDelayedMaterializingCTEsStep is applied for every DelayedCreatingSetsStep caller, but only the SELECT planner guarantees an outer DelayedMaterializingCTEsStep will replace the stripped safety net. Mutation plans built by MutationsInterpreter::buildSubqueryPlansForSetsAndAdd use forceMaterializeCTE inside the set subquery but do not add an outer materialized-CTE wrapper, so an ALTER TABLE ... WHERE x IN (WITH c AS MATERIALIZED (...) SELECT ... FROM c) shape can lose its only CTE writer/gate and hit the new is_built fail-fast.
Suggested fix: strip safety nets only when the caller provides an enclosing CTE materialization step, or add equivalent materialized-CTE wrapping for mutation/non-SELECT callers before DelayedCreatingSetsStep.
[src/QueryPipeline/QueryPipelineBuilder.cpp:808] DroppingTransform uses the main data header for totals/extremes inputs. The previous dropTotals path used each aux port's own header, and Pipe::addTransform intentionally allows totals to differ from the data header because TotalsHavingTransform can produce finalized totals while data remains not finalized. In that valid shape, connect will throw while trying to discard totals.
Suggested fix: let DroppingTransform take separate data/totals/extremes input headers, using pipe.getTotalsPort()->getSharedHeader() and pipe.getExtremesPort()->getSharedHeader() for aux inputs while keeping only data outputs.

Tests

⚠️ Add a focused mutation regression with enable_materialized_cte = 1, an ALTER TABLE ... UPDATE or DELETE condition using IN (WITH c AS MATERIALIZED (...) SELECT ... FROM c), and mutations_sync = 2.
⚠️ Add coverage that discarding totals/extremes works when the aux header differs from the main data header, either as a small processor test for DroppingTransform or a SQL query that reaches addCreatingSetsTransform/addMaterializingCTETransform with such totals.

Final Verdict

Status: ⚠️ Request changes

Minimum required actions: preserve materialized-CTE safety nets for non-SELECT set-plan callers, fix DroppingTransform aux-port headers, add the focused regressions above, and adjust the changelog metadata.

After the two-traversal split, makePlansForCTEs no longer calls plan->optimize -- that happens in DelayedMaterializingCTEsStep::optimizePlans during the first traversal. Drop the now-unused QueryPlanOptimizationSettings argument from the public method and from the local addPlansForMaterializingCTEs helper. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

EmeraldShift · 2026-05-16T09:00:30Z

Just for posterity -- other (probably bad) attempts to fix this by me:

A small utility to splice out a top-level `DelayedMaterializingCTEsStep` from a plan, replacing it with its single original child. Used by the upcoming change to `DelayedCreatingSetsStep::makePlansForSets` to strip the safety-net materialization step from set plans being attached for runtime execution. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

When a set's plan is being attached for runtime construction (via DelayedCreatingSetsStep → CreatingSetsStep), the safety-net DelayedMaterializingCTEsStep planted by forceMaterializeCTE is no longer needed: at runtime the outer MaterializingCTEsStep in the main plan materializes the CTE before the CreatingSetsStep's pipeline runs. The strip is non-recursive on purpose. Nested set subquery plans (reached via DelayedCreatingSetsStep inside this plan) may still be consumed by buildSetInplace / buildOrderedSetInplace during the subsequent plan->optimize() and need their safety-nets to claim. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The previous order claimed materialized-CTE plans at the outer level during resolveMaterializingCTEs before addStepsToBuildSets had a chance to trigger synchronous buildSetInplace / buildOrderedSetInplace via the recursive plan->optimize. When that synchronous inplace path then ran on a deeply nested IN-subquery filtered by a MergeTree primary key, the safety-net DelayedMaterializingCTEsStep inside the inplace pipeline saw the CTE's plan already moved out and degraded to a pass-through, producing LOGICAL_ERROR while reading the still-empty StorageMemory. Swapping the order lets the inplace path claim the CTE via the safety-net first; resolveMaterializingCTEs then materializes only the CTEs that the inplace path did not already handle, with main's outer step degrading to a pass-through in those cases. Closes #102320. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…sted IN Issue #102320: the CTE `a` is referenced once at top level and once inside a WHERE id IN (... WHERE id IN (...)) chain that hits a MergeTree primary key. The PK pruning on the outer IN-subquery triggers buildOrderedSetInplace for the inner IN-subquery, which used to read an empty StorageMemory because main's resolveMaterializingCTEs had already claimed the CTE before addStepsToBuildSets fired the inplace path. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

… CreatingSetStep wrapper Two fixes for cases the initial single-step strip missed: 1. `addBuildSubqueriesForMaterializedCTEsIfNeeded` stacks one `DelayedMaterializingCTEsStep` per CTE dependency level on top of a plan. An IN-subquery that transitively references a chain of CTEs gets multiple safety-net steps stacked, so stripping just the topmost one leaves the next one in place. The remaining safety-net claims its CTE in the wrong scope when the recursive `plan->optimize` below runs `resolveMaterializingCTEs`, attaching that CTE's plan inside the set subquery's `CreatingSetsStep` instead of at the outer `MaterializingCTEsStep` in the main plan. The fix loops while the top of the chain is `DelayedMaterializingCTEsStep`. 2. `DelayedCreatingSetsStep::makePlansForSets` calls `FutureSetFromSubquery::build` first, which wraps the source plan with `CreatingSetStep`. That makes the plan root a `CreatingSetStep` with the safety-net chain as its child, not at the root itself. The helper now peeks past one non-Delayed wrapper to reach the chain. Without (1), the third query in `03821_materialized_cte_with_sets` (`WITH b AS MATERIALIZED (SELECT uid FROM a, a), a AS MATERIALIZED ... SELECT count() FROM (SELECT * FROM b WHERE uid in b) ... LEFT SEMI JOIN a ...`) regressed because the main IN-subquery's safety-net stack was `Delayed[a] → Delayed[b] → body`: stripping only the top left `Delayed[b]` in place, and the recursive `plan->optimize` then claimed `b` inside the IN-subquery's `CreatingSetsStep`, leaving the join's right side reading `a.storage` before the outer step had a chance to materialize it. Without (2), the helper was a no-op for any plan reached via `makePlansForSets` (since `build` always wraps with `CreatingSetStep`), which is the only call site for it. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ix-mat-cte

Lets DelayedMaterializingCTEsStep::optimizePlans dedup the plan->optimize(...) call across multiple DelayedMaterializingCTEsStep instances that share the same MaterializedCTE pointer (e.g. UNION branches plus the UNION-level step). Logically parallel to the existing is_materialization_planned flag, but for the optimize stage rather than the claim/move stage. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Before this commit, `DelayedMaterializingCTEsStep::optimizePlans` (pass 1 of `resolveMaterializingCTEs`) called `cte->plan->optimize(...)` once per Delayed step that referenced the CTE. For shapes where multiple Delayed steps share one `MaterializedCTE` pointer -- e.g. UNION/INTERSECT/EXCEPT branches plus the UNION-level step, all planted by `addBuildSubqueriesForMaterializedCTEsIfNeeded` -- the same plan was optimized N times. Optimize is idempotent, so this was a CPU regression rather than a correctness bug, but it scales with the number of UNION branches and the optimization itself walks the CTE plan tree (and recursively triggers no-op `buildSetInplace` calls on already-built sets). Claim `is_plan_optimized` atomically before invoking optimize, mirroring the existing `is_materialization_planned` claim in `makePlansForCTEs`. Addresses review comment on PR #105041: #105041 (comment) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…al shape The dedup commit (3a0728b + 6c08747) reduces redundant plan->optimize(...) invocations across DelayedMaterializingCTEsStep instances that share a MaterializedCTE pointer. With the dedup in place, mergeExpressions no longer fires the second time during pass 1 of resolveMaterializingCTEs and the two adjacent ExpressionSteps in the local Union branch stay unmerged -- matching the pre-PR shape this test originally expected. Reverts the cosmetic update introduced in 5b2a827 (which adjusted the reference for the merged shape that pass-1's redundant optimize calls used to produce). Functional results (count() = 3 twice) are unchanged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Per the project rule "When mentioning logical errors, say 'exception' instead of 'crash', because they don't crash the server in the release build." Pure comment edit, no behavior change. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

novikd · 2026-05-18T19:36:19Z

The fix seems to be working; the only thing is that Bugfix validation (functional tests) is somehow broken (it seems it does not handle LOGICAL_ERROR without this fix properly).

novikd · 2026-05-19T09:29:01Z

Bugfix validation check was broken in #104081.

Details

  What actually happened on master (no-fix build)

  From bugfix_validation_functional_tests/job.log:

  - 14:19:09 — clickhouse-test … --jobs 9 -- 04227_… 04228_… starts
  - 14:20:15 — Hung check failed: server is not responding
  - 14:20:24 — Unable to locate any ClickHouse server process. It must have crashed or 
  exited prematurely!
  - 14:20:24 — Stopping tests, terminating all processes...
  - workers raise Terminated: 15 and exit before writing any [ FAIL ] line
  - 14:20:29 — Failed to reproduce the bug

  The LOGICAL_ERROR aborted the server (debug build), as evidenced by the artifact
  core.QueryCompPipeEx.1592-275296.zst.enc (core dump from the QueryCompletedPipelineEx…
  thread, 15-char comm truncation).

  Why the validation misreads it

  ci/jobs/scripts/functional_tests_results.py:13-15 defines:

  HUNG_SIGN         = "Found hung queries in processlist"
  SERVER_DIED_SIGN  = "Server died, terminating all processes"
  SERVER_DIED_SIGN2 = "Server does not respond to health check"

  None of these match what clickhouse-test actually emits today on the global-hung-check
  / server-crash path (tests/clickhouse-test:1117, 4898, 4903):

  ┌────────────────────────┬─────────────────────────────────────────────────────────┐
  │    Parser looks for    │             clickhouse-test actually emits              │
  ├────────────────────────┼─────────────────────────────────────────────────────────┤
  │ "Found hung queries in │ "Hung check failed: server is not responding"           │
  │  processlist"          │                                                         │
  ├────────────────────────┼─────────────────────────────────────────────────────────┤
  │ "Server died,          │                                                         │
  │ terminating all        │ "Stopping tests, terminating all processes..."          │
  │ processes"             │                                                         │
  ├────────────────────────┼─────────────────────────────────────────────────────────┤
  │ "Server does not       │ only in the per-test cleanup path                       │
  │ respond to health      │ (clickhouse-test:3444), which never runs here because   │
  │ check"                 │ workers were SIGTERM'd first                            │
  └────────────────────────┴─────────────────────────────────────────────────────────┘

clickhouse-gh · 2026-06-05T14:31:05Z

+        /// `subqueries`, not as children of any node in this tree) are
+        /// untouched — they keep their safety-nets for their own
+        /// `buildSetInplace` / `buildOrderedSetInplace` consumers.
+        removeAllDelayedMaterializingCTEsStep(*plan);


This unconditional strip assumes the set plan is being attached under a SELECT plan that still has an outer DelayedMaterializingCTEsStep for every referenced CTE. That is not true for the other DelayedCreatingSetsStep callers: MutationsInterpreter::buildSubqueryPlansForSetsAndAdd builds IN-subquery plans with forceMaterializeCTE, but the mutation plan never adds an outer materialized-CTE wrapper.

For a shape like ALTER TABLE ... UPDATE ... WHERE x IN (WITH c AS MATERIALIZED (...) SELECT ... FROM c), this removes the only DelayedMaterializingCTEsStep; plan->optimize then attaches a runtime set plan whose ReadFromMemoryStorageStep has no writer/gate and will hit the new is_built fail-fast (or read an empty StorageMemory without it). Please only strip these safety nets when the caller has an enclosing materialization step, or teach the mutation/non-SELECT callers to add that outer CTE materialization before DelayedCreatingSetsStep.

clickhouse-gh · 2026-06-05T14:31:05Z

+
+    bool has_totals = pipe.getTotalsPort() != nullptr;
+    bool has_extremes = pipe.getExtremesPort() != nullptr;
+    auto dropping = std::make_shared<DroppingTransform>(header, pipe.numOutputPorts(), has_totals, has_extremes);


DroppingTransform is constructed with the main data header for every input, including totals/extremes. That loses the old dropTotals behavior, which created a NullSink from each aux port's own header. Pipe::addTransform explicitly permits totals to have a different header from the data stream because TotalsHavingTransform can output finalized totals while data is not finalized.

In that valid shape, connect(*totals_port, *totals_in) will now throw while trying to discard totals, so a set/CTE subquery with such totals cannot be materialized. Please give DroppingTransform separate headers for data, totals, and extremes (or build the aux inputs from pipe.getTotalsPort()->getSharedHeader() / pipe.getExtremesPort()->getSharedHeader()) while keeping only the data outputs on the main header.

clickhouse-gh · 2026-06-05T17:43:54Z

LLVM Coverage Report

Metric	Baseline	Current	Δ
Lines	84.40%	84.50%	+0.10%
Functions	92.30%	92.30%	+0.00%
Branches	77.00%	77.10%	+0.10%

Changed lines: Changed C/C++ lines covered by tests: 176/201 (87.56%) | Lost baseline coverage: none · Uncovered code

Full report · Diff report

Cherry pick #105041 to 26.4: Fix LOGICAL_ERROR for reused materialized CTE filtered by IN over another materialized CTE

…TE filtered by IN over another materialized CTE

Cherry pick #105041 to 26.5: Fix LOGICAL_ERROR for reused materialized CTE filtered by IN over another materialized CTE

…TE filtered by IN over another materialized CTE

alexey-milovidov · 2026-06-09T02:30:33Z

novikd and others added 4 commits May 15, 2026 16:08

clickhouse-gh Bot added the pr-bugfix Pull request with bugfix, not backported by default label May 15, 2026

clickhouse-gh Bot reviewed May 15, 2026

View reviewed changes

Comment thread src/Processors/QueryPlan/Optimizations/addPlansForMaterializingCTEs.cpp

novikd marked this pull request as ready for review May 15, 2026 15:10

groeneai mentioned this pull request May 17, 2026

Parallelize reads from a single Parquet file in StorageFile, again #104431

Open

alexey-milovidov mentioned this pull request May 17, 2026

Stop the bleeding in function_prop_fuzzer #105146

Merged

1 task

This comment was marked as resolved.

Sign in to view

alexey-milovidov and others added 11 commits May 17, 2026 21:08

Merge branch 'master' into fix-mat-cte

057a3f5

Merge branch 'fix-mat-cte' of github.com:ClickHouse/ClickHouse into f…

f48c058

…ix-mat-cte

clickhouse-gh Bot added pr-critical-bugfix pr-must-backport Pull request should be backported intentionally. Use this label with great care! and removed pr-bugfix Pull request with bugfix, not backported by default labels May 18, 2026

novikd mentioned this pull request May 19, 2026

Execute materialized CTEs at plan-optimization time to fix pre-read crashes #103111

Closed

Merge remote-tracking branch 'origin/master' into fix-mat-cte-3

46bf468

clickhouse-gh Bot reviewed Jun 5, 2026

View reviewed changes

alexey-milovidov added this pull request to the merge queue Jun 6, 2026

Merged via the queue into master with commit 7c6a92c Jun 6, 2026
166 checks passed

alexey-milovidov deleted the fix-mat-cte branch June 6, 2026 16:09

robot-ch-test-poll4 added the pr-synced-to-cloud The PR is synced to the cloud repo label Jun 6, 2026

robot-ch-test-poll4 added a commit that referenced this pull request Jun 6, 2026

Merge pull request #106638 from ClickHouse/cherrypick/26.4/105041

1cae10c

Cherry pick #105041 to 26.4: Fix LOGICAL_ERROR for reused materialized CTE filtered by IN over another materialized CTE

robot-clickhouse added a commit that referenced this pull request Jun 6, 2026

Backport #105041 to 26.4: Fix LOGICAL_ERROR for reused materialized C…

036ab10

…TE filtered by IN over another materialized CTE

robot-ch-test-poll4 added a commit that referenced this pull request Jun 6, 2026

Merge pull request #106640 from ClickHouse/cherrypick/26.5/105041

b5c2e68

Cherry pick #105041 to 26.5: Fix LOGICAL_ERROR for reused materialized CTE filtered by IN over another materialized CTE

robot-clickhouse added a commit that referenced this pull request Jun 6, 2026

Backport #105041 to 26.5: Fix LOGICAL_ERROR for reused materialized C…

bca529a

…TE filtered by IN over another materialized CTE

robot-ch-test-poll4 mentioned this pull request Jun 6, 2026

Backport #105041 to 26.5: Fix LOGICAL_ERROR for reused materialized CTE filtered by IN over another materialized CTE #106641

Closed

robot-clickhouse-ci-2 added the pr-must-backport-synced The `*-must-backport` labels are synced into the cloud Sync PR label Jun 6, 2026

This was referenced Jun 7, 2026

Restore subquery plans after failed in-place set build #102308

Draft

Revert "Fix LOGICAL_ERROR for reused materialized CTE filtered by IN over another materialized CTE" #106795

Merged

robot-ch-test-poll2 added the pr-backports-created Backport PRs are successfully created, it won't be processed by CI script anymore label Jun 9, 2026

This was referenced Jun 9, 2026

Fix flaky 04295_04278_materialized_cte_in_union_runtime_set on ParallelReplicas variant #106717

Closed

Add integration tests for attach/detach and restart of Iceberg tables #91583

Merged

Pin version tweak to 1 in PR builds #107138

Merged

clickgapai mentioned this pull request Jun 12, 2026

LOGICAL_ERROR with materialized CTE #102320

Closed

clickgapai mentioned this pull request Jun 25, 2026

SEGV / LOGICAL_ERROR when materialized CTE is used in IN subquery of another materialized CTE referenced in a join #101940

Closed

groeneai mentioned this pull request Jul 1, 2026

Support strides for the QBit data type #108103

Merged

1 task

Sunbelt Computer Software

PL/B Language Development and Support

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Fix LOGICAL_ERROR for reused materialized CTE filtered by IN over another materialized CTE#105041

Fix LOGICAL_ERROR for reused materialized CTE filtered by IN over another materialized CTE#105041
alexey-milovidov merged 34 commits into
masterfrom
fix-mat-cte

novikd commented May 15, 2026 •

edited by robot-clickhouse

Loading

Uh oh!

clickhouse-gh Bot commented May 15, 2026 •

edited

Loading

Uh oh!

Uh oh!

EmeraldShift commented May 16, 2026

Uh oh!

This comment was marked as resolved.

novikd commented May 18, 2026

Uh oh!

novikd commented May 19, 2026

Uh oh!

clickhouse-gh Bot Jun 5, 2026

Uh oh!

clickhouse-gh Bot Jun 5, 2026

Uh oh!

clickhouse-gh Bot commented Jun 5, 2026

Uh oh!

Uh oh!

alexey-milovidov commented Jun 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

Sunbelt Computer Software

PL/B Language Development and Support

Uh oh!

Conversation

novikd commented May 15, 2026 • edited by robot-clickhouse Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Motivation

Root cause

Fix

Test plan

Changelog category (leave one):

Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):

Documentation entry for user-facing changes

Version info

Uh oh!

clickhouse-gh Bot commented May 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

AI Review

Summary

PR Metadata

Findings

Tests

Final Verdict

Uh oh!

Uh oh!

EmeraldShift commented May 16, 2026

Uh oh!

This comment was marked as resolved.

novikd commented May 18, 2026

Uh oh!

novikd commented May 19, 2026

Uh oh!

clickhouse-gh Bot Jun 5, 2026

Choose a reason for hiding this comment

Uh oh!

clickhouse-gh Bot Jun 5, 2026

Choose a reason for hiding this comment

Uh oh!

clickhouse-gh Bot commented Jun 5, 2026

LLVM Coverage Report

Uh oh!

Uh oh!

alexey-milovidov commented Jun 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

novikd commented May 15, 2026 •

edited by robot-clickhouse

Loading

clickhouse-gh Bot commented May 15, 2026 •

edited

Loading