Skip to content

Antalya 26.3: Bump to 26.3.17#2096

Open
zvonand wants to merge 281 commits into
antalya-26.3from
bump/antalya-26.3/26.3.17
Open

Antalya 26.3: Bump to 26.3.17#2096
zvonand wants to merge 281 commits into
antalya-26.3from
bump/antalya-26.3/26.3.17

Conversation

@zvonand

@zvonand zvonand commented Jul 21, 2026

Copy link
Copy Markdown
Member

Changelog category (leave one):

  • Not for changelog (changelog entry is not required)

CI/CD Options

Exclude tests:

  • Fast test
  • Integration Tests
  • Stateless tests
  • Stateful 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)
  • 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)

grantholly-clickhouse and others added 30 commits June 9, 2026 12:20
…5464

Backport ClickHouse#105464 to 26.3: Fix SIGSEGV when reading Dynamic subcolumns from compressed Memory table after ALTER
…6802

Backport ClickHouse#106802 to 26.3: Fix inconsistent columns on exception (i.e. MEMORY_LIMIT_EXCEEDED) during parsing
…6692

Backport ClickHouse#106692 to 26.3: Fix segfault due to use-after-free in NATS
…6411

Backport ClickHouse#106411 to 26.3: Fix backup FILE_DOESNT_EXIST for refreshable materialized view targets
…tion ID for Date instead of silent overflow or LOGICAL_ERROR on ALTER
…rageRegistry::renameTable during batch renames
…locatedWithoutCheck/MemoryAllocatedWithoutCheckBytes in release build
…5985

Backport ClickHouse#105985 to 26.3: Bump libxml2 from 2.15.1 to 2.15.3
…4101

Backport ClickHouse#104101 to 26.3: Fix LOGICAL_ERROR in StreamingStorageRegistry::renameTable during batch renames
…1644

Backport ClickHouse#101644 to 26.3: Do not apply lazy materialization for plans with array join
…5246

Backport ClickHouse#105246 to 26.3: Fix wrong `OSIOWaitMicroseconds` for leaking stats
…4250

Backport ClickHouse#104250 to 26.3: Reject out-of-range integer partition ID for Date instead of silent overflow or LOGICAL_ERROR on ALTER
…0899

Backport ClickHouse#100899 to 26.3: Increment profile events MemoryAllocatedWithoutCheck/MemoryAllocatedWithoutCheckBytes in release build
…bles with ORC files and PREWHERE enabled
…5847

Backport ClickHouse#105847 to 26.3: Fix on-fly mutation LowCardinality pass-through column conversion
…7096

Backport ClickHouse#107096 to 26.3: Fix spurious ZooKeeper session recreation on config reload
…7097

Backport ClickHouse#107097 to 26.3: Do not hold mutex across ZooKeeper reads in access entities refresh
alexey-milovidov and others added 21 commits July 15, 2026 11:56
… poll for async "Restored console logger level" line
…0033

Backport ClickHouse#110033 to 26.3: Fix flaky test_server_no_logging: poll for async "Restored console logger level" line
…7970

Backport ClickHouse#107970 to 26.3: Fix flaky test 04146_iceberg_orc_row_policy_prewhere on release branches
…0263

Backport ClickHouse#110263 to 26.3: Fix heap-buffer-overflow when serializing a shared quantileTDigest state
…9449

Backport ClickHouse#109449 to 26.3: Embed metrics definitions into dashboard
…7145

Backport ClickHouse#107145 to 26.3: Fix query condition cache poisoning by on-fly mutations
…2628

Backport ClickHouse#102628 to 26.3: Fix LOGICAL_ERROR crash in Parquet reader for nullable columns with filter
…8034

Backport ClickHouse#108034 to 26.3: Reschedule the background data-parts refresh task after an exception
…7040

Backport ClickHouse#107040 to 26.3: Fix crash moving an empty part to a plain_rewritable disk
…0233

Backport ClickHouse#110233 to 26.3: Fix reading Iceberg tables sorted on special-char column names
…8214

Backport ClickHouse#108214 to 26.3: Mask secrets in query_views_log
@github-actions

github-actions Bot commented Jul 21, 2026

Copy link
Copy Markdown

Workflow [PR], commit [1861670]

@zvonand

zvonand commented Jul 22, 2026

Copy link
Copy Markdown
Member Author

@blau-ai

@blau-ai

blau-ai commented Jul 22, 2026

Copy link
Copy Markdown
Collaborator

CI triage for #2096 (26.3.16 → 26.3.17 bump)

Verdict: 8 distinct failing checks — 1 PR-caused (real bug, has a fix below), 1 real-but-pre-existing (fuzzer), 1 needs a baseline compare, and 5 that are infra/expected-for-a-bump. Not CI-green, but only one item is a genuine regression introduced by this bump and it has a small, clear fix.

Check Class PR-caused?
Stateless (amd_debug, parallel) + (…, s3 storage) real bug Yes — incomplete backport
BuzzHouse (amd_debug) real bug, latent No (pre-existing, fuzzer-found)
RegressionTests / Iceberg (2) / iceberg_2 test failures Needs baseline compare
GrypeScan{Keeper,Server,Server-alpine} (+3 status checks) infra No
DCO expected No
FinishCIReport / PR aggregate gates No

1. Stateless tests — 04308_arrow_oob_reads_valuePR-caused, fix below

Both debug stateless jobs fail on the same test, deterministically:

04308_arrow_oob_reads_value:  [ FAIL ]
+FAIL [uuid] expected INCORRECT_DATA (exit=0);   got: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
+FAIL [uuid] expected INCORRECT_DATA (exit=139); got: <empty output>      # 139 = segfault

Only the last (uuid) sub-check fails; the other 8 pass. Both the test and the code it exercises arrived in this bump via e3d6c73dd18 "Backport ClickHouse#106395 to 26.3: Arrow IPC: fix heap out-of-bounds reads…"git branch -r --contains e3d6c73dd18 shows it is only on this bump branch, not on antalya-26.3, so this is new here.

Root cause: the backport is incomplete. Every sibling reader in src/Processors/Formats/Impl/ArrowColumnToCHColumn.cpp validates the data buffer against the declared row count before reading (validateChunksBeforeReserve(… checkedCastFixedSizeBinary …)), but readColumnWithUUIDFromFixedBinaryData (line ~900) does not — it uses a raw assert_cast and only checks byte_width(), never the buffer size:

const auto & fixed_binary_array = assert_cast<const arrow::FixedSizeBinaryArray &>(arrow_chunk);
if (fixed_binary_array.byte_width() != sizeof(UUID)) throw …;   // width only, not length×width
for (int64_t i = 0; i < fixed_binary_array.length(); ++i)        // length is attacker-forged (16384)
    std::memcpy(&res, fixed_binary_array.GetValue(i), 16);       // reads past the 16-byte buffer → OOB → garbage / segfault

The test forges the row count to 16384 while the buffer holds 1 row, so GetValue(i) reads out of bounds — returning garbage (aaaa…, exit 0) or crashing (exit 139). Upstream ClickHouse/ClickHouse master already guards this path (its readColumnWithUUIDFromFixedBinaryData calls validateChunksBeforeReserve + checkedCastFixedSizeBinary); the 26.3 backport just dropped those two lines. This is a real read-out-of-bounds on malformed Arrow input, so it's worth fixing rather than muting the test.

Suggested fix (mirrors upstream — both helpers already exist in this branch):

--- a/src/Processors/Formats/Impl/ArrowColumnToCHColumn.cpp
+++ b/src/Processors/Formats/Impl/ArrowColumnToCHColumn.cpp
@@ static ColumnWithTypeAndName readColumnWithUUIDFromFixedBinaryData(
     auto column = type_hint->createColumn();
     auto & column_data = assert_cast<ColumnVector<UUID> &>(*column).getData();
-    column_data.reserve(arrow_column->length());
+
+    /// Reject a wrong fixed-size width before reserving: a FixedSizeBinary(1) read with a UUID hint
+    /// would otherwise reserve 16x the (attacker-controlled) row count before the per-chunk check.
+    const auto * fixed_type = assert_cast<const arrow::FixedSizeBinaryType *>(arrow_column->type().get());
+    if (static_cast<size_t>(fixed_type->byte_width()) != sizeof(UUID))
+        throw Exception(ErrorCodes::INCORRECT_DATA,
+            "Cannot read UUID from Arrow FixedSizeBinary array with byte_width != {}", sizeof(UUID));
+
+    /// Validate every chunk's data buffer covers the declared rows before reserving/reading.
+    validateChunksBeforeReserve(*arrow_column, [&](const arrow::Array & chunk) { checkedCastFixedSizeBinary(chunk, column_name); });
+    column_data.reserve(arrow_column->length());

     for (int chunk_i = 0, num_chunks = arrow_column->num_chunks(); chunk_i < num_chunks; ++chunk_i)
     {
-        const auto & arrow_chunk = *(arrow_column->chunk(chunk_i));
-        const auto & fixed_binary_array = assert_cast<const arrow::FixedSizeBinaryArray &>(arrow_chunk);
-
-        // Security check: Ensure we actually got 16 bytes per row
-        if (fixed_binary_array.byte_width() != sizeof(UUID))
-            throw Exception(ErrorCodes::INCORRECT_DATA,
-                "Cannot read UUID from Arrow FixedSizeBinary array with byte_width != {}", sizeof(UUID));
-
+        const auto & fixed_binary_array = checkedCastFixedSizeBinary(*(arrow_column->chunk(chunk_i)), column_name);
         for (int64_t i = 0; i < fixed_binary_array.length(); ++i)

(The per-element loop body is unchanged. checkedCastFixedSizeBinary validates byte_width × length ≤ buffer size per chunk, so the forged length is rejected as INCORRECT_DATA — which is exactly what the .reference expects.)


2. BuzzHouse (amd_debug) — real, but pre-existing (not this bump)

Crash is SIGABRT, Code: 49 (LOGICAL_ERROR) from executeQueryImpl at executeQuery.cpp:1240:

throw Exception(LOGICAL_ERROR, "Inconsistent AST formatting: the query:\n{}\ncannot parse query back …")

This is the debug-only AST format→re-parse roundtrip self-check tripping on a fuzzer query:
EXPLAIN ESTIMATE INSERT INTO t13 (…) SELECT … FROM generateRandom('…Variant(FixedString(147),Time64(3),Tuple(c3 Date))…') — it re-serializes as EXPLAIN ESTIMATE (INSERT …) (INSERT wrapped in parens) which then fails to parse back. It's a general AST-formatting defect in EXPLAIN ESTIMATE INSERT, unrelated to a patch-level version bump — BuzzHouse generates fresh random queries each run and surfaces different latent bugs. Not a merge blocker for this bump; worth a separate issue for the query-formatting owners. Recommend confirming a BuzzHouse run on antalya-26.3 reproduces it (it should).


3. RegressionTests / Iceberg (2) / iceberg_2needs a baseline compare

13 scenarios fail, all concentrated in one Altinity-antalya feature, /iceberg/export partition/ (catalogs, transactions, casting/lossy, casting/out_of_bounds), each an AssertionError. The suite runs with --output new-fails, i.e. these are flagged relative to the regression baseline. I can't fetch the report.html or a base-branch baseline from this container (no network), so I can't definitively call it PR-caused vs. baseline drift. Because the failures are deterministic and clustered in one feature (not scattered/flaky), the two likely explanations are (a) a real interaction with 26.3.17's casting changes, or (b) test-vs-version drift in the clickhouse-regression baseline. Ask: could the regression owner compare this iceberg_2 run against the latest antalya-26.3 baseline? If it's green there, it's a real regression to chase; if red there too, it's pre-existing.


4. Grype scans (3 jobs + 3 status checks) — infra, not PR-caused

All fail with the same Grype-side error, not a vulnerability:

WARN error updating db … UNIQUE constraint failed: operating_systems.name … (2067)
ERROR failed to load vulnerability db: database does not exist
##[error]Process completed with exit code 1

The Grype vulnerability DB failed to download/migrate on the runner. The status lines even read "Grype Scan Completed with 0 high/critical vulnerabilities." Safe to re-run once the Grype DB mirror is healthy.

5. DCO — expected for a version bump

"129 commits incorrectly signed off" — these are the upstream ClickHouse backport commits merged in via the v26.3.17 tag; upstream commits don't carry Altinity DCO sign-offs. Normal for a bump PR and handled by the maintainer at merge time, not a code defect.

6. FinishCIReport / PR — aggregate gates

These just reflect that the jobs above are red; they carry no independent failure.


Bottom line / next steps

  • Only Update README.md #1 is a real regression introduced by this bump, and it's a genuine OOB-read fix. I can deliver the one-file patch above. Since the mention didn't specify delivery, I haven't pushed anything — want me to open a blau/* PR with this fix, or commit it directly onto bump/antalya-26.3/26.3.17?
  • Update README.md #4 (Grype), Update README.md #5 (DCO), Update README.md #6 (aggregates) need no code change — re-run Grype / normal bump handling.
  • Update README.md #2 (BuzzHouse) — file separately; not a blocker for the bump.
  • Update README.md #3 (Iceberg export-partition) — needs a baseline comparison from the regression owner to classify.

Analysis only; I can't build/run ClickHouse in this container, so correctness of the proposed fix would be confirmed by CI on the PR. Evidence: run 29845885999, commit efa360f.

@zvonand

zvonand commented Jul 24, 2026

Copy link
Copy Markdown
Member Author

@blau-ai

@blau-ai

blau-ai commented Jul 24, 2026

Copy link
Copy Markdown
Collaborator

CI triage for #2096 (Bump to 26.3.17)

Verdict: 0 of the failures are caused by this PR's code. All red checks are infra/tooling or external test-suite issues. Breakdown: 1 workflow-config fix we can port here (Grype), 1 external test-suite bug (OAuth), 1 localized suite/behavior item worth a human look (Iceberg export-partition), and 1 process check (DCO, expected for bump PRs). The FinishCIReport red is just the aggregate gate reflecting the above.

This is a pure version bump (26.3.15 → 26.3.17, 588 files, all upstream backports/merges) — no hand-written product code — which is consistent with the findings below.


1. Grype Scan ×3 (server, server-alpine, keeper) — infra, not PR-caused, fixable here

Decisive log line (Run Grype Scan step, all three images fail identically):

WARN error updating db error=unable to activate new vulnerability database: failed to hydrate database:
     failed to open db: unable to migrate: constraint failed: UNIQUE constraint failed: operating_systems... (2067)
ERROR failed to load vulnerability db: database does not exist
##[error]Process completed with exit code 1.

Grype never scanned — its vulnerability DB failed to load with the pinned anchore/grype:v0.92.2. The "Completed with 0 high/critical vulnerabilities" in the status is misleading: create_summary reads a stale/empty result.json, and Set commit status marks failure only because the Parse grype results step was skipped (state = parse_grype.outcome=='success' ? success : failure), not because any CVE was found.

This is already fixed on the Stable branches — PRs #2064 / #2058 / #2063 ("Fix Grype Scan: bump grype to v0.115.0"). The fix is a one-line version bump that antalya-26.3 hasn't received yet:

# .github/grype/run_grype_scan.sh
-GRYPE_VERSION=${GRYPE_VERSION:-"v0.92.2"}
+GRYPE_VERSION=${GRYPE_VERSION:-"v0.115.0"}
# .github/workflows/grype_scan.yml
-  GRYPE_VERSION: "v0.92.2-arm64v8"
+  GRYPE_VERSION: "v0.115.0"

Suggested fix: port #2064 onto antalya-26.3. I can open this as a blau/* PR — see the note at the bottom.

2. Regression — OAuth — external test-suite bug, not PR-caused

The feature errored at import time (it never exercised the ClickHouse binary):

✘ 29m 26s [ Error ] /oauth
    ModuleNotFoundError: No module named 'oauth.tests.concurrency'
      File ".../oauth/regression.py", line 318, in regression
      File ".../importlib/__init__.py", line 90, in import_module

oauth/regression.py imports oauth.tests.concurrency, which doesn't exist in the checked-out Altinity/clickhouse-regression suite. That single error is what produced "1 feature (1 errored)" and cascaded into "192 retries failed". Nothing in this ClickHouse PR can affect it — the fix belongs in the regression repo (add the missing module or pin a compatible suite ref).

3. Regression — Iceberg (2) — localized; not attributable to this PR's code, worth a human look

62/192 features and 195/2133 scenarios failed, all confined to the /iceberg/export partition/... feature — every other Iceberg/S3/Parquet suite passed (iceberg_1: 43/43 ok; s3_export_part, s3_export_partition, parquet, swarms: all green). Failures are uniform, fast (~600 ms) AssertionErrors across the whole export-partition subtree, including even the "rejected: unsupported expression" negative cases. That pattern = a systematic mismatch between the external suite's expectations and this build's behavior for one feature, not scattered flakiness.

Because it's a pure backport bump, this is most likely suite-expectation drift for the Antalya "export partition to Iceberg" feature rather than a code regression introduced here — but I can't prove it from logs alone. I couldn't fetch the S3 HTML report from this container (no network tools). Suggested next step: a human opens one failing scenario's assertion diff in the iceberg_2 report to confirm suite-drift vs. a real export-partition change, and pin/refresh the clickhouse-regression ref accordingly.

4. DCO — process check, expected for a bump PR

ACTION_REQUIRED. A bump PR merges dozens of upstream ClickHouse merge/backport commits that carry no Signed-off-by trailer, so DCO flags them. This is the normal state for these bump PRs and is resolved by a maintainer override / DCO allowlist — no code change, and not something I can (or should) force.

5. FinishCIReport — aggregate gate

Fails only because 1–4 are red; no independent failure of its own.


Health check

The substantive build/test signal on this bump is healthy: Stateless, Integration (amd_binary — 0 failures across all shards), Stress, SQLLogic, and the other regression suites (iceberg_1, parquet, parquet_minio, parquet_aws_s3, s3_export_part, s3_export_partition, swarms) are all green. The four red checks are a stale Grype pin, one broken external OAuth test module, one localized Iceberg export-partition suite delta, and the routine DCO trailer requirement — none of them a defect in the 26.3.17 code being merged.

Delivery

The only fix that lives in this repo is the Grype version bump (#2 OAuth and #3 Iceberg are in clickhouse-regression; #4 DCO is a maintainer action). Since the request didn't specify a delivery mode, I haven't pushed anything. Want me to open a blau/* PR porting the Grype bump (#2064) onto antalya-26.3, or commit it directly to bump/antalya-26.3/26.3.17?

🤖 automated CI triage by @blau-ai — evidence from run 30077179403

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.