Antalya 26.8: Antalya 26.6 allow non matching schema export partition by name

[zvonand]

Changelog category (leave one):

• New Feature

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

Renamed the export_merge_tree_part_schema_mismatch_mode setting for EXPORT PART/EXPORT PARTITION to export_merge_tree_part_schema_match_mode, with values position (default, same behavior as before) and name, which matches destination columns to source columns by name instead of position. Added the export_merge_tree_part_ignore_extra_source_columns setting, which allows a source column without a matching destination column to be dropped instead of rejected with NUMBER_OF_COLUMNS_DOESNT_MATCH, in either matching mode (#2284 by @k-morozov).

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 #2284.

---

Related: #2220

Documentation entry for user-facing changes

...

[github-actions]

Workflow [PR], commit [58ec0d8]

[zvonand]

@blau-ai

[blau-ai]

CI triage

Verdict: 4 failing checks, 0 caused by this PR. All are pre-existing/flaky/infra. This PR touches only EXPORT PART/EXPORT PARTITION schema-matching (renames the export_merge_tree_part_schema_mismatch_mode enum → export_merge_tree_part_schema_match_mode + adds export_merge_tree_part_ignore_extra_source_columns), its export code, and the export integration tests. None of the failures touch that surface, and the PR's own export integration tests passed (the only integration failure was in an unrelated suite). No code change is needed to go green — re-running the flaky jobs should clear three of them; the Grype one is an image-level CVE for the platform team.

Head SHA analyzed: 58ec0d8.

---

1. Stress test (amd_debug) — ❌ not PR-related (flaky / slow startup)

• Report: Cannot start clickhouse-server, Failures: 2/2.
• Decisive evidence: the final server restart never finished booting inside the 120s probe window. At the moment the probe gave up (Connection refused … port 9000), the log shows the server still actively loading Outdated parts of the system-log tables (system.text_log, system.metric_log, system.zookeeper_log, …), followed by Failed to start server.
• No crash, no <Fatal>, empty fatal.log/application_errors.txt. The only <Error> lines are expected stress fault-injection (MEMORY_LIMIT_EXCEEDED: fault injected (at specific point)) and infra noise (Listen … DNS error: Address family … not supported IPv6, CgroupsReader: Cannot find 'kernel'). No UNKNOWN_SETTING, nothing referencing export_merge_tree_part_*.
• Classic debug-build stress slow-startup timeout after the run accumulated many system-log parts. Unrelated to a settings-enum rename.
• Next step: re-run. Safe.

2. Integration tests (arm_binary, distributed plan, 3/4) — ❌ not PR-related (flaky timing test)

• The only failure in the shard is test_s3_cluster/test.py::test_graceful_shutdown → assert errors == 0 / assert 1 == 0 (1/1933).
• The test launches 10 concurrent threads hammering s3Cluster(...) queries, then does SYSTEM STOP SWARM MODE + stop_clickhouse(kill=True) mid-flight and asserts zero query errors across all threads. That's an inherently timing-sensitive graceful-shutdown race; one thread seeing an error is a textbook flake.
• Nothing in this PR touches s3Cluster, swarm mode, or distributed query. Integration shards 1/4, 2/4, 4/4 were green, and this PR's own export tests passed.
• Next step: re-run the shard. Safe.

3 & 4. Grype Scan (clickhouse-keeper + clickhouse-server -alpine) — ❌ not PR-related (base-image CVE)

• Each reports "Grype Scan Completed with 1 high/critical vulnerabilities" against the built container images.
• This PR changes only C++/settings/docs and export tests — no Dockerfiles, no dependency/lockfile, nothing that adds a package to the images. The finding is a CVE in the base image / packaged deps, not introduced by this diff, and shows up on other PRs built from the same base.
• Next step: not actionable from this PR; it's a base-image bump for the platform/release team. Treat as a known non-blocker for merge unless policy requires the image rebuilt on a patched base.

---

Health check

The PR itself looks healthy. The enum rename and the new export_merge_tree_part_ignore_extra_source_columns setting are threaded consistently through Settings.cpp/.h, SettingsEnums.*, and SettingsChangesHistory.cpp; the NAME-mode export logic lives in ExportPartitionUtils/ExportPartTask; and the matching integration + gtest coverage passed where it ran. No failure in this run points at the diff. I'd just re-trigger the Stress and Integration (3/4) jobs; the Grype hit is an image-level CVE to route to the platform team rather than a code fix here.

Note: I can't build or run ClickHouse in this container — this triage is from CI reports (praktika S3 + job logs); correctness of the change is ultimately validated by a green CI re-run.