Antalya 26.8: Fixed refreshing of glue metadata after ALTER calls

[zvonand]

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

Fixed an issue where Glue DataLakeCatalog tables could retain stale schema metadata after ALTER TABLE operations. #2085 (#2272 by @subkanthi).

CI/CD Options

Exclude tests:

• Fast test
• Integration Tests
• Stateless tests
• Stateful tests
• Performance tests
• All with ASAN
• All with TSAN
• All with MSAN
• All with UBSAN
• All with Coverage
• All with Aarch64
• 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)
• Parquet (1.5h)
• RBAC (1.5h)
• SSL Server (1h)
• S3 (2h)
• S3 Export (2h)
• Swarms (30m)
• Tiered Storage (2h)

Cherry-picked from #2272.

[github-actions]

Workflow [PR], commit [bef921e]

[zvonand]

@blau-ai

[blau-ai]

CI triage for #2467 (feature/antalya-26.8/pr-2272 → antalya-26.8)

Verdict: 4 failing checks, 0 caused by this PR. All are pre-existing/flaky/infra. This PR only changes src/Databases/DataLake/GlueCatalog.{cpp,h} and tests/integration/test_database_glue/test.py — none of the failures touch the Glue/Iceberg catalog code path, and none touch dependencies, Dockerfiles or startup code. No code change is needed; the two test jobs just need a re-run.

Head SHA analyzed: bef921e08526e1cc3d0b75483fb9f7d7738e346f.

---

1. Stress test (arm_debug) — flaky / infra, not PR-related

• Report: Failures: 2/2 → sub-results Cannot start clickhouse-server + Check failed (exit code 1).
• test_results.tsv contains only Cannot start clickhouse-server\tFAIL.
• Evidence it is not a PR crash: fatal.log and application_errors.txt are both 0 bytes — no crash, no stack trace. The server log shows the instance started and ran merges normally, then the stress harness restarts it (debug build + ThreadFuzzer, "It will work slowly") and the restart did not become responsive within the timeout. This is the classic debug-stress restart-timeout pattern.
• The PR's Glue catalog code is instantiated lazily only when a Glue database engine is used — it is never on the server startup path, so it cannot cause a startup/restart failure.
• Next step: re-run the job. Safe to ignore unless it reproduces with a non-empty fatal.log.

2. Integration tests (arm_binary, distributed plan, 3/4) — flaky, not PR-related, non-blocking

• Single failure: test_s3_cluster/test.py::test_graceful_shutdown — assert errors == 0 → assert 1 == 0 (1/1923).
• CI marked this result do_not_block_pipeline_on_failure: true and labeled it retry_failed (a known-flaky entry).
• The test is a concurrency/timing test: it launches 10 threads of s3Cluster(...) queries, issues SYSTEM STOP SWARM MODE, then kills a node and asserts zero query errors while a node is being hard-killed. It is inherently timing-sensitive and lives in test_s3_cluster — unrelated to the Glue catalog change in this PR.
• Next step: re-run; this is a well-known flaky test and does not block the pipeline.

3 & 4. Grype Scan (keeper: 4 high/critical; server -alpine: 1 high/critical) — base-image CVEs, not PR-related

• These scan the built container images (altinityinfra/clickhouse-keeper and clickhouse-server:*-alpine) for OS-package / bundled-dependency vulnerabilities.
• This PR changes only C++ and Python source — no Dockerfile, no contrib/ submodule, no dependency manifest — so it cannot add or remove image CVEs. These findings are inherited from the base image and will appear identically on other PRs built from the same base rebase-cicd-v26.8.1.2041-lts.
• Next step: handle via the normal base-image / CVE-bump process, not in this PR. Not a merge blocker for this change.
• (The GrypeScanKeeper / Grype Scan and GrypeScanServer (-alpine) / Grype Scan Actions jobs are the same two scans.)

---

PR health check

Builds (amd/arm debug, binary, release, wasm), Fast test (11,197 passed), all Stateless suites (amd_debug parallel/sequential, distributed-plan s3), the other three Integration shards (1/4, 2/4, 4/4), AST fuzzer, BuzzHouse, SQLLogic, SQLStorm, Parser memory check and Compatibility checks are all green. The only reds are the two known-flaky test jobs and the image CVE scans described above — none attributable to the diff. From a CI standpoint this cherry-pick of #2272 looks healthy; I'd just re-run the Stress (arm_debug) and Integration 3/4 jobs to get them green.

(Automated triage — I can't build/run ClickHouse in this environment; conclusions are from the praktika S3 reports and the diff. Correctness of the change itself is exercised by the green functional/integration suites above.)