Antalya 26.6 Backport of #109199 - Fix alter with custom disk

[ilejn]

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):

This patch fixes ALTERS for MergeTree tables for which the disk setting was specified (ClickHouse#109199 by @Michicosun)

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)
• 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 [ae18875]

[ilejn]

Attn @zvonand
This PR substitutes #2241

[ilejn]

Failing tests are unlikely caused by the PR, look like infra issues e.g.

random/select/slt_good_108.test:25327
    Reason: actual result has exception and canonic result doesn't, details: actual: query execution failed with an exception, original is: Code: 241.
DB::Exception: (total) memory limit exceeded: would use 1.37 GiB (attempt to allocate chunk of 0.00 B), current RSS: 26.00 GiB, maximum: 25.91 GiB.. Stack trace:

[zvonand]

@blau-ai

[blau-ai]

CI triage for #2246 — @zvonand

Verdict: 2 distinct failures, both NOT caused by this PR (0 PR-caused, 1 infra/flaky, 1 pre-existing base-image scan). Everything that actually exercises this change is green, including the test the backport adds.

This PR is source-only (disk-setting resolution in AlterCommands / MergeTreeData / MergeTreeSettings). Builds (amd_debug, amd_binary, amd/arm_release), Fast test, all Stateless suites (parallel, sequential, s3), Stress test, AST fuzzer, BuzzHouse, SQLStorm, Install packages, Docker images and CI Tests all passed. Notably, the new functional test this backport ships — 04498_alter_table_with_custom_disk — ran in the Stateless suites with Failed: 0, so the fix itself behaves.

---

1. SQLLogic test — FAIL → infra / flaky, not PR-related

Threshold line:

FAILED: total tests 4,831,729 < minimum 5,939,581; OK: failed tests 149,989 <= maximum 174,004; FAILED: 23,650 new failures detected

The 23,650 "new failures" are all the same thing — the server hitting its memory cap on random SELECT queries:

DB::Exception: (total) memory limit exceeded: would use 1.37 GiB (attempt to allocate chunk of 0.00 B), current RSS: 26.00 GiB, maximum: 25.91 GiB. ... Code: 241
random/select/slt_good_108.test:25312 ... actual result has exception and canonic result doesn't

Both symptoms point to one cause: the job ran under memory pressure (RSS pinned at ~26 GiB against a 25.91 GiB limit), so thousands of slt_good_108 SELECTs failed with MEMORY_LIMIT_EXCEEDED and the run was cut short (4.8M of the required 5.9M queries executed). These are pure generated-SELECT tests — they never touch ALTER … MODIFY SETTING disk=…, custom disks, or any code path this PR changes. This is the well-known resource-sensitivity of the Antalya SQLLogic job, not a regression here.

• Evidence: current_failures.txt / report_thresholds.log under .../PRs/2246/ae18875…/sqllogic_test/; the check even ships a "Failure history for this test" (cidb) link scoped to base_ref IN ('antalya-26.6','antalya'), i.e. it recurs on the base branch.
• Next step: safe to re-run the SQLLogic job. No code change warranted. If it keeps OOMing across re-runs it's a runner/threshold issue for CI to tune, still independent of this PR.

2. Grype Scan (…-alpine) — FAIL → pre-existing base-image CVE, not PR-related

Grype Scan Completed with 1 high/critical vulnerabilities

Grype scans the built clickhouse-server:…-alpine container for OS/dependency CVEs. A C++ source change to ALTER/disk handling cannot introduce or remove an image vulnerability; this is a property of the Alpine base image and is shared by other PRs/branches. Next step: hand off to whoever owns base-image bumps (or accept/annotate the finding); nothing to fix in this PR.

PR check — this is just the aggregate gate; it's red only because the two children above are red.

---

Bottom line: nothing here blocks the correctness of the backport. Re-running SQLLogic is the only PR-side action, and it should be treated as flaky/infra. I did not push any changes (analysis-only request).