Release pull request for branch 26.7 - #111451

Backport #115396 to 26.7: Complete ZooKeeper finalization before logging exceptions

…-written manifest and manifest-list files

The custom-setting test walked the tiers up to 3, which does not exist here, so
it left the server at 2 and every later test that asserts tier 0 failed too.

Backport #111786 to 26.7: Fix missing Iceberg field-ids in ClickHouse-written manifest and manifest-list files

Backport #113156 to 26.7: Fix allow_feature_tier for MergeTree settings

Backport #110437 to 26.7: Serialize iceberg metadata log content lazily

… ARRAY JOIN

…ation of JSON and Dynamic columns

…mKahan` over `Nullable` when the aggregated batch does not start at row 0

Backport #115852 to 26.7: Fix performance regression in text serialization of JSON and Dynamic columns

…r names and values

Backport #116057 to 26.7: Fix ILLEGAL_COLUMN for an empty IN set with ARRAY JOIN

… in the -ForEach and -Map combinators

…ings with special characters

…cate columns in the reading header

Backport #116990 to 26.7: Fix wrong results from `sumKahanIf` and `sumKahan` over `Nullable` when the aggregated batch does not start at row 0

… test

`04846_materialized_view_target_is_materialized_view` asserts that
`CREATE MATERIALIZED VIEW ... TO ... POPULATE` reaches the hop this fix refuses and
fails with `NOT_IMPLEMENTED`. Master and 26.8 accept that combination, so there the
population insert runs and is refused on the hop. Every older branch still rejects
`TO` together with `POPULATE` while parsing, in `ParserCreateQuery.cpp`, and answers
Code 62 instead:

    Code: 62. DB::Exception: When creating a materialized view you can't declare
    both 'TO [db].[table]' and 'POPULATE': Expected server error: 48. (SYNTAX_ERROR)

The unmodified test is green on master and 26.8 and fails on 26.3, 26.6, 26.7 and
the private release/26.4 and release/26.6 branches, reproducibly: the
randomized-settings diagnosis failed every run it attempted.

So expect `SYNTAX_ERROR` and say in the comment what the arm checks here. This gives
up the population-insert route to the hop, which is unreachable on this branch, but
the two direct `INSERT INTO v_view_target` arms above it do cover the fix and already
passed - the client aborts at this statement, which is why the arms below it had not
run yet. The trailing comment about `v_populate` surviving a non-atomic population no
longer applies either, since the view is never created. The reference file is
unchanged: the statement adds no rows either way, so both counts still hold.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

#118684 gave `DatabaseFilesystem`'s constructor a fourth parameter with no default
value. On master the factory in `DatabaseFilesystem.cpp` is the only place that
constructs one, so the change compiles there. This branch still has a second call
site that master no longer has: `createClickHouseLocalDatabaseOverlay` in
`programs/local/LocalServer.cpp`, which master rewrote to register a `DatabaseURL`
over `file://` instead, in a change that was never backported. Every build job
failed on it, each with a single error:

    programs/local/LocalServer.cpp: note: in instantiation of function template
    specialization 'std::make_shared<DB::DatabaseFilesystem, const std::string &,
    const char (&)[1], std::shared_ptr<const DB::Context> &, 0>' requested here
    allocator_traits.h:302:5: error: no matching function for call to '__construct_at'

Pass `false`, which keeps the behaviour this call site had. The flag only suppresses
the `Path does not exist` refusal while the server replays its own stored metadata,
and this overlay is registered fresh on every `clickhouse-local` start over an empty
path, which resolves to the current directory.

Adding a default argument to the declaration would also build, but it would leave the
header differing from master's and would hand the permissive value to any call site
added later. Naming the argument here keeps every ported file identical to master and
states the choice at the one place that has to make it.

26.8 needs none of this: it already carries the `DatabaseURL` rewrite, which is why
its backport merged green.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…er one

The previous commit set the expected code for this arm to `SYNTAX_ERROR`, which is
the code this branch answers with, but left the hint as `serverError`, so the test
still failed with the code it asked for:

    Code: 62. DB::Exception: When creating a materialized view you can't declare
    both 'TO [db].[table]' and 'POPULATE':
    Expected server error: 62. (SYNTAX_ERROR)

The refusal comes from `ParserCreateQuery`, so the client hits it while splitting the
multi-query file and never sends the statement. `ClientBase` rethrows unconditionally
in that case when the hint names a server error, whatever the code is:

    case MultiQueryProcessingStage::PARSING_EXCEPTION:
        if (hint.hasServerErrors())
        {
            // Syntax errors are considered as client errors
            current_exception->addMessage("\nExpected server error: {}.", hint.serverErrors());
            current_exception->rethrow();
        }

`03601_temporary_views.sql` annotates the same parser refusal of `POPULATE` as
`clientError SYNTAX_ERROR`, so follow it here.

The parse exception makes the client skip the rest of the line and carry on, so the
arms below this one did run on the previous attempt: 4757 and 11835 other tests
passed in the two jobs that reported this failure, which covers the refreshable-view
arm and both count assertions.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Backport #119618 to 26.7: Do not leave a `Filesystem` database pointing at a removed directory, which makes the server refuse to start

Backport #115985 to 26.7: Refuse an insert into a materialized view whose target is a view

Backport #118684 to 26.7: Load a `Filesystem` database whose directory is gone instead of refusing to start

`StorageObjectStorageCluster::drop` was cherry-picked with the
`master` call shape `dropTable(namespace, table, delete_data)`. The
third argument comes from the `iceberg_delete_data_on_drop` support
which is not in this branch, where `ICatalog::dropTable` still takes
only the namespace and the table name, so every build failed with
`too many arguments to function call, expected 2, have 3`.

Call the two-argument overload, matching
`StorageObjectStorage::drop` in this branch, and drop the now-unused
`iceberg_delete_data_on_drop` declaration.

`test_catalog_commit_conflict_reaches_caller_at_once` counts the
`RestCatalog` log line `updateMetadata conflict` to see that a
refused commit was handed back to the sink at once. That line was
added by the Snowflake Horizon REST catalog work (`344e80f34b9c`),
which is on 26.8 and master only. In this branch
`RestCatalog::updateMetadata` swallows every `HTTPException` with
`LOG_TRACE(log, "Unsucceeded request {}", ...)` instead, so the
count is always zero and the test fails its own premise:

  AssertionError: no writer was refused, so nothing about conflict handling was exercised

Rewording the pattern would only pin this branch's unrelated logging,
so the test is dropped here. The change itself - `409 Conflict` is
not retriable - stays covered by
`05055_http_conflict_is_not_retried`, which asserts that a `409`
reaches the caller after exactly one request.

`test_writes_manifest_list_partition_summary` asserts the raw bytes
of the manifest-list partition summary, and it is the first test to do
so, which is why it fails on this branch for every parametrisation
while it is green on master:

  At index 1 diff: (False, None, b'\x0b\x00\x00\x00\x00\x00\x00\x00', ...) != (False, None, b'\x0b\x00\x00\x00', ...)

The `Int32` partition bound is written as 8 bytes where Appendix D of
the Iceberg specification requires 4. `dumpValue` sizes its output as
`sizeof(T)` with `T` deduced from its argument, and
`Field::safeGet<Int32>` returns `NearestFieldType<Int32>`, which is
`Int64`, so the branch asks for an `Int32` and gets an 8-byte value.

Narrow before `dumpValue` sees it, with the same `static_cast<Int32>`
the neighbouring small-integer branch already uses. This is the source
half of `3dc6b4f4ef32` (#117571, `Closes #117072`), which never got a
backport label; this branch needs it because the test it adds pins the
spec width. That test is the coverage here, so the stateless test of
the original commit is left out rather than duplicated.

The data-file bounds are corrected by the same line, so this branch
stops writing manifests that `pyiceberg` refuses to plan a filtered
scan over (`unpack requires a buffer of 4 bytes`). No reader change is
needed in either direction: `ColumnVector::insertData` ignores the
buffer length and does `unalignedLoad<T>(pos)`, so an existing 8-byte
bound still decodes.

Related: #117571
Related: #117072

`04869_distributed_plan_partial_aggregation_bucket_order` fails
reproducibly on this backport: the planner picks `Shuffle` instead of
partial aggregation plus a memory-efficient merge, so the `EXPLAIN`
prints `GatherExchange / Aggregating / ShuffleExchange` where the
reference has `MergingAggregated (merge) / GatherExchange /
Aggregating (partial)` - and the test never reaches the code this
pull request fixes.

The distributed rewrites run post-order, so `tryMakeDistributedRead`
has already inserted a `GatherExchangeStep` above the read by the time
`tryMakeDistributedAggregation` calls `estimateReadRowsCount`. With
the estimation unable to look through an exchange it returns no stats
at all, and the strategy falls back to `Shuffle` "to be safe". The
row-count hint never reaches the read step, which is why lowering
`cardinality` did not help.

`0fae364ef698` ("Make row count estimation look through exchange steps
in non-cloud builds") is a commit of this very pull request and it
removed those two `CLICKHOUSE_CLOUD` guards. It was lost from the
backport: PR #86353 (Cascades) removed the same guards on `master`
three days before #114523 merged, so by merge time the hunk was a
no-op in the pull request's net diff, and the backport carries only
that net diff. `master` and `26.8` have no `CLICKHOUSE_CLOUD` left in
this file; this branch still had both guards.

The guarded include is dropped rather than unguarded, because the
same header is already included unguarded further down, which leaves
this file exactly as `master` has it.

…acle the minimum of several runs

…er sanitizers

`04780_json_subcolumn_index_match_not_quadratic` failed with

    FAIL: tokens index analysis over a constant with 100000 dots allocated
    4216780 bytes, more than 150% of the no-dots control (22224 bytes)

and the harness's own reruns then passed twice, both with and without
the randomized settings. This branch still measures a single run,
while `master` takes the minimum of three (#114608, 2026-08-13) - and
that commit's comment names this exact pair of byte counts as the
failure it was written for. #114608 is now labelled for 26.6 and 26.7,
so the oracle will stop being a single sample once it lands; this
merge re-triggers the workflow in the meantime.

`04408_array_fold_cancellation` failed with

    -TIMEOUT_EXCEEDED
    +runtime throw: no timeout

and the harness's own reruns then passed five times out of five. The
test builds the array with `range(120000)` on this branch, while
`master` halved it to `range(60000)` (#110942, 2026-07-18) precisely
because "a longer array makes that setup rival `max_execution_time`,
so under sanitizers the query can be killed by the outer `timeout`
before the in-function check fires" - and the failing job is the
`amd_asan_ubsan` one. #110942 is now labelled for 26.6 and 26.7; this
merge re-triggers the workflow in the meantime.

The earlier run of this branch also died on `Logical error: 'Bucket 4
is pushed twice'`, which is a pre-existing 26.6/26.7 abort in
`04605_parallel_replicas_merging_aggregated_bucket_order` unrelated to
validating a MySQL `BIT` length - it has hit a dozen unrelated 26.7
pull requests in three weeks, and the `chassert` that turns it into a
dead server is only replaced by a thrown exception on `master` and
26.8.

Backport #119238 to 26.7: Don't use backoffs on concurrent inserts conflicts

Backport #119214 to 26.7: Parallel replicas for object storage writes

Backport #118796 to 26.7: Iceberg manifest list partition summaries

…BOTH '' FROM x)` is used where a function is expected

Backport #112414 to 26.7: Write per-file statistics into Iceberg manifest entries on INSERT

Backport #114608 to 26.7: Make the 04780 index-analysis allocation oracle the minimum of several runs

Backport #114523 to 26.7: Fix wrong results of the partial aggregation strategy in distributed query plans

Backport #119680 to 26.7: Validate the length of a `BIT` column value coming from MySQL

Backport #110942 to 26.7: Fix flaky 04408_array_fold_cancellation under sanitizers

…mn of a Variant or Dynamic column

…ammar

Two statements of the new test assert behaviours that arrived in master with #112788, after the 26.7 branch cut:

- `ALTER TABLE ... MODIFY COLUMN c Int64 STATISTICS(...)` silently drops the column-level `STATISTICS` clause here, so no type validation runs and the expected `INCORRECT_QUERY` is never thrown. The statement is removed; the `ALTER TABLE ... ADD STATISTICS` line keeps the `ALTER` slot covered.
- Column modifiers must be written in the fixed order `COMMENT`, `CODEC`, `STATISTICS`, `TTL` on this branch, so `STATISTICS(tdigest) CODEC(ZSTD(3))` is a syntax error. The `CREATE TABLE ok` line is rewritten with `CODEC` before `STATISTICS`; `ASTColumnDeclaration` already formats it in that order, so the expected output is unchanged.

CI report: https://s3.amazonaws.com/clickhouse-test-reports/json.html?PR=119856&sha=03e5c7fd77e86da6abee8ab725a382bd0ffb4cd3&name_0=BackportPR&name_1=Stateless%20tests%20%28amd_asan_ubsan%2C%20distributed%20plan%2C%20parallel%29
PR: #119856

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Backport #112338 to 26.7: Fix a crash when reading a nullable subcolumn of a Variant or Dynamic column

Backport #119317 to 26.7: Fix a crash and a LOGICAL_ERROR when `trim(BOTH '' FROM x)` is used where a function is expected