Stable 26.3: bump to 26.3.53.4

[mkmkme]

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
• 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 [4980aee]

[mkmkme]

@blau-ai

[blau-ai]

CI triage — @mkmkme

Verdict: 1 failing check, 0 PR-caused. Every other check (all builds, Fast test, Quick functional, Unit tests asan/ubsan, the 4 amd_asan stateless shards, AST fuzzer, integration, Grype) is green. The only red is Stateless tests (amd_debug, parallel) — Failed: 12, Broken: 2. All 14 are timeout flakiness on the slow debug build, not regressions from this rebase.

Why these are not PR-caused

Every one of the 12 FAILs is a timeout-class failure — no output diffs, no crashes, no sanitizer traps:

Kind	Tests
Code: 160 ... TOO_SLOW (estimated query time > 600 s)	04033_tpc_ds_q47 (601 s), q49 (647 s), q64 (642 s), q78 (730 s), 00071_merge_tree_optimize_aio (754 s)
Timeout exceeded while receiving data from server (300 s)	04033_tpc_ds_q09, 04033_tpc_ds_q14
Harness Timeout! Processes left in process group (600 s wall)	00154_avro, 00091_prewhere_two_conditions, 00152_insert_different_granularity, 03582_pr_read_in_order_hits, 03634_autopr_output_bytes_estimation

Concrete evidence it's infra/flaky, not this PR:

1. These match CI's own known-flaky rule. broken_tests_handler.log runs each failure against the rule "KNOWN: Random timeout with sanitizer", whose message regex (Timeout! Processes left in process group | Timeout exceeded while receiving data from server | Estimated query execution time (…) too long) matches these exactly. The rule is just scoped to check_types: [tsan, asan, msan, ubsan] — it does not list debug. So on this amd_debug job the handler logs Skip rule: Check types didn't match and the same tolerated timeout surfaces as a hard FAIL instead of being downgraded to BROKEN. This is a classification gap in the CI harness, not a code defect.
2. Only the debug variant is affected. The debug binary is ~several× slower than release/sanitizer builds, and these are the heaviest queries in the suite — TPC-DS analytical queries over an S3 "web" disk (04033_tpc_ds_q* is tagged no-flaky-check with the comment "TPC-DS queries are too expensive for thread fuzzer"; q64 even links upstream slow-query issue ClickHouse#95168), plus the big test.hits scans. Under parallel load on a busy runner they blow the fixed 600 s estimate / 300 s receive timeout. The amd_asan stateless shards, unit tests (asan + ubsan) and Fast test all passed — a real performance regression introduced by the backports would show on those too.
3. Nature of the PR. Stable 26.3: bump to 26.3.53.4 #2589 is the stable-26.3 → 26.3.53 rebase/bump: its contents are upstream backports (TTL merges, croaring bump, codec/Keeper/Iceberg fixes, etc.). None touch the generic MergeTree read hot path in a way that would uniformly slow unrelated TPC-DS and hits queries by the amounts seen.

The 2 "Broken" are the same story — timeouts that did match a tolerance rule and were downgraded; they're already non-blocking.

Suggested next step

No code change is needed on this PR. Just re-run the Stateless tests (amd_debug, parallel) job — these timeout tests are expected to pass (or intermittently shuffle) on a less-loaded runner. Hold the merge on a green re-run of that single job rather than on a diff.

Optional CI-infra follow-up (separate from this PR, upstream-side): add debug to the check_types of the "Random timeout with sanitizer" known-broken rule so debug-build timeouts are downgraded to BROKEN the same way sanitizer builds already are — that would stop this exact false-red from recurring on every slow debug run.

_{Analysis from CI artifacts only (no local build/test in this environment); correctness is confirmed by the re-run on CI. Report: result_pr.json + broken_tests_handler.log for sha 14c67f3.}

[mkmkme]

Note to a reviewer: I additionally backported ClickHouse#125569 to this pr which reverts ClickHouse#116724. The reason for that is our CI got significantly slower to the point that stateless tests in debug build got timed out and failed. This revert was backported to 26.8, but not to 26.3.

We should consider backporting ClickHouse#126138 to 26.3 stable when it's merged.

[mkmkme]

@blau-ai

[blau-ai]

CI triage — PR #2589 (bump to 26.3.53.4)

Verdict: 1 failing test, 0 PR-caused. The only red check is a single stateless test that fails only when CI randomly rolls encrypted storage on. It's a test defect inherited verbatim from the upstream backport, not something the version bump broke, and it lands in a lane CI explicitly marks non-blocking. Safe to merge; a one-line fix makes it green.

Everything else is green or skipping. Builds, Fast test, Integration, Regression, and all other Stateless lanes passed.

---

The one failure

Stateless tests (amd_debug, distributed plan, s3 storage, parallel) — Failed: 1, Passed: 9398, Skipped: 356, Broken: 2
(the suite node carries "do_not_block_pipeline_on_failure": true, i.e. non-gating; the 2 "Broken" are the known 03441_deltalake_* "S3 sometimes unreachable" tests.)

Failing test: 05082_kill_and_system_on_cluster_access_types (failed on the original run and the retry — retry_failed label).

Decisive log line:

KILL TRANSACTION local -> FAIL: ... Code: 60. DB::Exception:
Unknown table expression identifier 'system.transactions' ... (UNKNOWN_TABLE)

Root cause (fully traced)

1. The test was newly introduced on this branch by the robot backport of upstream Require the local privilege for KILL and SYSTEM statements over ON CLUSTER ClickHouse/ClickHouse#118360 (Require the local privilege for KILL and SYSTEM statements over ON CLUSTER, commit d8a85b1). The KILL TRANSACTION ... -> allowed arms run KILL TRANSACTION, which internally does SELECT ... FROM system.transactions.
2. system.transactions is attached only when allow_experimental_transactions is set — src/Storages/System/attachSystemTables.cpp:281.
3. That setting comes from tests/config/config.d/transactions.xml, which tests/config/install.sh:126-128 installs only when encrypted storage is off.
4. ci/jobs/functional_tests.py:150 picks encrypted storage at random: is_encrypted_storage = random.choice([True, False]), and :255-257 turns it into --encrypted-storage for s3/azure lanes. This run rolled it on → no transactions.xml → no system.transactions → UNKNOWN_TABLE.

So it's config-randomized flakiness over a real test bug: the test hard-requires system.transactions but doesn't declare that dependency. It passed in the other stateless lanes (encrypted storage rolled off) and would pass on a re-run that rolls off (~50%).

Why it is not PR-caused

• This is a version-bump/rebase PR; the failing test is upstream content pulled in, not a change the bump authored.
• #118360 only added privilege checks; the SELECT FROM system.transactions under KILL TRANSACTION is pre-existing behavior, so this is not a product regression — just a missing test guard.

Concrete fix

Every other transaction-dependent stateless test in the repo already carries the no-encrypted-storage tag (01133_begin_commit_race, 01168_mutations_isolation, 01169_alter_partition_isolation_stress, 03167_transactions_are_really_disabled, 03920_drop_db_hang_with_trx). The backport simply forgot it. One-line fix:

--- a/tests/queries/0_stateless/05082_kill_and_system_on_cluster_access_types.sh
+++ b/tests/queries/0_stateless/05082_kill_and_system_on_cluster_access_types.sh
@@ -1,4 +1,5 @@
 #!/usr/bin/env bash
+# Tags: no-encrypted-storage
 
 CUR_DIR=$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)

no-encrypted-storage is both necessary and sufficient — under plain s3 storage (encrypted off) transactions.xml is present, so the test passes there. Ideally the same tag goes upstream too.

PR health check

This is a clean version bump (26.3.52 → 26.3.53.4) carrying accumulated upstream 26.3 backports. Builds are green across asan/ubsan/debug/binary, Fast test is green (0 failed), and the entire Integration/Regression/other-Stateless matrix passed. The only red is the randomized-config test-guard gap above, in a non-blocking lane. I'd consider the PR mergeable; applying the one-liner just removes the noise.

---

I can open a blau/* PR with that one-line tag fix, or you can take the diff directly. Want me to open the PR? (I won't push to rebase/stable-26.3/26.3.52 unless you ask for a direct commit.)

_{Report data: praktika result_pr.json for 25cd28d + job broken_tests_handler.log. I can't build/run ClickHouse in this container, so correctness of the fix is validated by CI.}