Antalya 25.8 Backports of #88440, #95301 - Fix sparse columns aggregation for any overflow mode

[mkmkme]

Same as #1396, but for Antalya

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 into CHANGELOG.md):

Fix aggregation of sparse columns when group_by_overflow_mode is set to any (ClickHouse#88440 by @korowa and ClickHouse#95301 by @mkmkme)

[mkmkme]

I'll self-verify this once the CI finishes.

[github-actions]

Workflow [PR], commit [6e5a8a2]

[mkmkme]

@blau-ai

[blau-ai]

CI triage for #2077

Verdict: 6 failing checks — 0 caused by this PR. All are infra/flaky/pre-existing regression noise. The code area this PR touches is green: the AggregateFunctions (1), (2), (3) regression suites and the aggregate-related integration tests all passed, and the change compiled cleanly on 8 of 9 build configs (the 9th was killed by the runner, not a compile error). No code change is needed — the failed jobs just need a re-run.

---

1. Build (amd_release) — infra timeout/hang → re-run

• Step Run was killed with exit code -15 (SIGTERM) after 2h 4m, while every other build config finished normally: amd_binary 12m, amd_ubsan 14m, amd_asan 16m, amd_tsan 18m, amd_msan 21m, amd_debug 15m, arm_release 1h14m.
• A 2h+ runtime ending in SIGTERM (vs ~15m elsewhere) is a hung/reclaimed runner, not a build error (a compile error exits 1, and the same source built fine everywhere else — including the tsan build that then ran integration tests).
• Not PR-caused. Safe to re-run.

2. Integration tests (amd_tsan, 4/6) — flaky backup test → re-run

• fail: 1, passed: 738, broken: 1. The single failure is:
  test_backup_restore_on_cluster/test_cancel_backup.py::test_shutdown_cancels_backup
• This is a backup-cancellation-on-shutdown timing test with no relationship to aggregate functions or sparse columns. Known-flaky area.
• Not PR-caused. Safe to re-run.

3. Regression aarch64 — rbac_2, alter_attach_1, alter_move (aarch64-only flakes)

• rbac_2 fails in /rbac/part 2/SQL security/cascading views cleanup:
  Code: 630. DB::Exception: User ... is used as a definer in views [...]. (HAVE_DEPENDENT_OBJECTS) on DROP USER IF EXISTS — a test teardown-ordering flake in the SQL-security suite.
• rbac_2, alter_move, and alter_attach_1 all PASSED on the x86/Release regression run — the failures appear only on the aarch64 runners. An aggregate-function change cannot fail RBAC/ALTER-PARTITION tests on one architecture only.
• Not PR-caused. Re-run the aarch64 jobs.

4. Regression session_timezone (aarch64 + x86) — pre-existing suite failure

• Both arches fail the same scenario: /session timezone/clickhouse local/date datetime column types — a clickhouse local DateTime('UTC') parsing check asserting an expected message is in the output. Timezone/DateTime parsing, unrelated to sparse-column aggregation.
• Deterministic on both arches ⇒ a pre-existing expectation drift in this regression suite on antalya-25.8, not introduced here.
• Not PR-caused. Worth confirming against a base-branch run and, if reproducible there, tracking as a separate regression-suite issue.

PR gate + Build (amd_release) check-run

• The aggregate PR gate and the duplicate Build (amd_release) check-run are red only because of the jobs above; they'll clear once those pass.

---

Recommendation

Re-run Build (amd_release), Integration tests (amd_tsan, 4/6), and the failed aarch64 regression jobs. Nothing in the diff (a null-place guard in addBatchSparse for AggregateFunctionSum / IAggregateFunctionHelper, removal of redundant addBatchSparse overrides in the TimeSeries functions, plus two new stateless tests) is implicated by any of these failures. If session_timezone keeps failing after a re-run, it's a pre-existing suite issue to file separately, not a blocker for this backport.

_{🤖 Automated CI triage. I can't build/run ClickHouse in this container — this is evidence-based from CI logs and downloaded regression artifacts.}