Stable 25.8 Backport of #123431 - Fix analyzer setting in views over Distributed

[mkmkme]

Fix analyzer setting in views over Distributed

Changelog category (leave one):

• Critical Bug Fix (crash, data loss, RBAC)

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

Fix a possible crash when querying the view over Distributed with enable_analyzer=0 (ClickHouse#123431 by @mkmkme)

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 [e62b4f0]

[mkmkme]

@blau-ai

[blau-ai]

CI triage — #2495 (backport of ClickHouse#123431)

Verdict: 4 red checks, 0 caused by this PR. 2 are an infra/runner problem (stress-test server couldn't start), 2 are Docker base-image CVE scans. The umbrella PR status is red only because it aggregates those. This PR only touches InterpreterSelectQuery::initSettings (query-time code) plus one new stateless test — none of the failures sit on that path, and all functional suites that actually ran (Integration, AST fuzzer, BuzzHouse, Regression, all Builds) are green.

1–2. Stress test (amd_debug) and Stress test (amd_ubsan) — ❌ infra, not PR-related

Both report check_status.tsv doesn't exists, which means the job died before producing results. The job log shows the server never opened port 9000 — clickhouse-client ... Connection refused (localhost:9000) × 60 retries → Failed to start server.

Root cause is in the server error log (identical in both builds): the server aborts during startup while loading metadata, trying to reach the Azure blob-storage emulator (Azurite):

<Error> Application: Caught exception while loading metadata:
Azure::Storage::StorageException, e.what() = 500 ... Code: 111, Connection refused
  ... DB::AzureBlobStorage::getContainerClient(...)
  ... DB::Context::getDatabaseDisk() const
  ... DB::DatabaseCatalog::initializeAndLoadTemporaryDatabase()
  ... DB::Server::main(...)

The server retried startup several times and kept hitting Connection refused to Azurite, so it never came up.

This is a runner/environment issue (Azure emulator not reachable), not a code defect:

• It's in Azure object-storage disk init at startup, which this PR does not touch.
• The same +debug / +ubsan binaries start fine in other jobs — AST fuzzer (amd_debug) and AST fuzzer (amd_ubsan) both passed, and they boot a server from these builds. A real startup regression would have taken those down too.
• Both sanitizers failed the exact same way → shared infra, not a build-specific bug.

Next step: just re-run the two Stress test jobs. No code change is warranted.

3–4. GrypeScanKeeper and GrypeScanServer (-alpine) — ❌ pre-existing base-image CVE, not PR-related

• Grype Scan altinityinfra/clickhouse-keeper:... → Completed with 1 high/critical vulnerabilities
• Grype Scan altinityinfra/clickhouse-server:...-alpine → Completed with 1 high/critical vulnerabilities
• (For contrast, the non-alpine GrypeScanServer / Grype Scan passed with 0.)

Grype scans OS/library packages baked into the Docker images. This PR changes exactly one .cpp file and adds one SQL test — it cannot add or remove an image-level CVE. This is a pre-existing vulnerability in the (alpine) base image / keeper image, independent of the change. Full reports are linked from the two failing checks' target URLs (.../PRs/2495/<sha>/grype/.../results.html).

Next step: out of scope for this backport; handle via the usual base-image CVE bump if it's gating the release. Not something to fix in this PR.

PR (umbrella status) — red only by aggregation

Goes green once the two Stress test jobs are re-run (assuming the Azurite infra is healthy) and the Grype CVE is addressed separately.

---

Note: I can't build or run ClickHouse in this environment — this triage is from the praktika S3 reports and CI logs. Correctness of the backport itself is validated by the green functional suites above.