[mkmkme]

Changelog category (leave one):

• Bug Fix (user-visible misbehavior in an official stable release)

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

Fix NOT_FOUND_COLUMN_IN_BLOCK in the native Parquet V3 reader (regression from ClickHouse#93542) when a PREWHERE had conjuncts sharing a common intermediate expression. (ClickHouse#107059 by @groeneai)

Documentation entry for user-facing changes

...

CI/CD Options

Exclude tests:

• Fast test
• Integration Tests
• Stateless tests
• Stateful tests
• Unit tests
• Performance tests
• Aarch64 tests
• All with ASAN
• All with TSAN
• All with MSAN
• All with UBSAN
• All with Coverage
• All Regression
• Disable CI Cache

Regression jobs to run:

• Fast suites (mostly <1h)
• Aggregate Functions (2h)
• Alter (1.5h)
• Benchmark (30m)
• CAS (content-addressed storage; Antalya only)
• ClickHouse Keeper (1h)
• Iceberg (2h)
• LDAP (1h)
• OAuth (5m)
• Parquet (1.5h)
• RBAC (1.5h)
• SSL Server (1h)
• S3 (2h)
• S3 Export (2h)
• Swarms (30m)
• Tiered Storage (2h)

[github-actions]

Workflow [PR], commit [e943179]

[mkmkme]

@blau-ai

[blau-ai]

CI triage — 1 failure, not PR-related (flaky/infra)

Summary: One check is red — Stateless tests (amd_asan_ubsan, distributed plan, parallel, 2/2) with Failed: 1. The failing test is 03572_export_merge_tree_part_limits_and_table_functions, which is unrelated to this PR's code and self-diagnosed as flaky by CI. Everything else (all builds, all other stateless shards including the two new parquet tests, unit tests, stress, fuzzers, regression) is green. No PR-related failures. Nothing to fix here — safe to re-run.

Stateless tests (amd_asan_ubsan, distributed plan, parallel, 2/2) — not PR-caused (flaky)

Decisive output:

2026-10-21 10:58:35 Reason: result differs with reference:
-All exports completed.
+Timeout waiting for exports to complete after 60s

The test waits up to 60s for async EXPORT PART operations to finish; on this run the exports were still in-flight when the 60s budget expired (several exports were already visible in part_log, just not all).

Why it's not this PR:

• This PR touches only src/Processors/Formats/Impl/Parquet/Reader.cpp (native Parquet V3 reader prewhere splitting) plus two new 04327/04342 parquet regression tests. It has nothing to do with MergeTree part export or table functions.
• 03572_export_merge_tree_part_limits_and_table_functions is a pre-existing EXPORT-PART test, not modified on this branch.
• CI's built-in randomized-settings diagnosis already re-ran it with the exact same settings and it passed:

  Runs: 1, Failed: 0, Passed: 1 — "All reruns passed. The failure is not reproducible (likely a transient issue)."

This is a load/timing timeout on the ASAN+UBSAN runner, i.e. infra/flaky.

Suggested next step: just re-run the failed amd_asan_ubsan … 2/2 shard; no code change needed. If this export-timeout keeps recurring across unrelated PRs, bumping the 60s export wait in that test would be worth a separate ticket — but that's a test-infra concern, not something this backport should carry.

Health check of the PR

The backport itself looks healthy. The actual fix (Parquet V3 prewhere split fallback) compiled on all four build variants and passed every stateless shard where it runs, and both new regression tests — 04327_parquet_v3_prewhere_shared_intermediate (the NOT_FOUND_COLUMN_IN_BLOCK repro) and 04342_parquet_v3_prewhere_intermediate_name_collision (the silent wrong-results guard) — are green, confirming the fix behaves as intended. The parquet regression suites (parquet, parquet_minio, parquet_aws_s3) all passed too. The one red mark is purely the flaky export-timeout above.

[mkmkme]

@blau-ai

[blau-ai]

CI triage — PR #2623

Verdict: 2 red checks, 0 PR-caused. Both are pre-existing flakes/infra, unrelated to the Parquet V3 prewhere change. The aggregate PR gate is red only because it inherits these two. The PR's own new regression tests (04327_parquet_v3_prewhere_shared_intermediate, 04342_parquet_v3_prewhere_intermediate_name_collision) passed in every stateless suite they ran in.

---

1. Stateless tests (amd_asan_ubsan, cas s3 storage, parallel, 1/2) — 04312_client_chime_on_slow_query_92718

Not PR-caused — flaky.

• The diff is a single line of pty/timing noise:

  -11. clickhouse-client --chime 1, slow query then error, pty stderr: BEL
  +11. clickhouse-client --chime 1, slow query then error, pty stderr: no BEL
  

  The test checks whether clickhouse-client emits a terminal bell (\a) on slow queries over a pty — it has nothing to do with Parquet, the native reader, or PREWHERE.
• CI's own randomized-settings diagnosis confirms it: "Re-running with the same randomized settings… Runs: 2, Failed: 0, Passed: 2. All reruns passed. The failure is not reproducible (likely a transient issue)."

Next step: safe to re-run; nothing to fix here.

2. Stress test (amd_asan_ubsan) — "Hung check failed, possible deadlock found" (1/5)

Not PR-caused — stress hung-check flake/infra.

• The hung-check thread dump is dominated by unrelated fuzzer queries (e.g. multiIf([[1]], …) raising ILLEGAL_TYPE_OF_ARGUMENT in 02021_exponential_sum_shard) and a DB::StorageObjectStorage construction stack — i.e. object-storage table setup, not the Reader::preparePrewhere() path this PR touches.
• The change is narrow and gated behind input_format_parquet_use_native_reader_v3; nothing in it introduces locking or background work that a hung check would catch. Stress hung-check failures are a well-known flaky category here, and the companion Stress test (amd_asan_ubsan, cas s3 storage) and the debug stress variants all passed.

Next step: safe to re-run.

---

Health check

The change is confined to Reader::preparePrewhere() in the native Parquet V3 reader and only activates when needs_filter is true, so it's a no-op for the common path. All builds, Fast test, Unit tests, Integration tests, the debug/distributed/binary/release stateless suites, AST fuzzer, BuzzHouse, SQLLogic/SQLStorm and the regression (parquet/iceberg) suites are green, and the two targeted regression tests added by the PR pass. The two red checks are an unrelated client-bell flake and a stress hung-check flake. Re-running both should turn CI green; no code change is needed.