We were unable to construct the commit group for this pull request: None of the pull request's commits have been successfully processed as yet.

Pin `merge_max_block_size` in `05210_skip_index_type_from_alter_session_setting` #121126

Open
groeneai opened 1:36am on September 20, 2026 wants to merge 0 commits into clickhouse/clickhouse master from
pin-merge-max-block-size-in-05210-granule-oracle

Pull Request Overview

  • Opened on September 20, 2026
  • Status Open
  • Commit count 0

Total Delta

0 Total Diff Delta

Open Days

Open 0 weekdays

Test Delta

0 Diff Delta in Test Files
Breakdown by Phase

How long has this pull request spent in each phase of its lifecycle?

Data pending calculation for pull request

Author avatar

Pin `merge_max_block_size` in `05210_skip_index_type_from_alter_session_setting`

Related: https://github.com/ClickHouse/ClickHouse/pull/119799

Changelog category (leave one):


  • CI Fix or Improvement (changelog entry is not required)

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

...

Description

05210_skip_index_type_from_alter_session_setting failed once on master in Stateless tests (amd_tsan, parallel) (report): the first assertion flipped 1 to 0, and the runner's minimization isolated --merge_max_block_size 110 (52/52 reproducible).

Root cause. The test asserts an exact Granules: 16/32 on the merged part. A merge computes index granularity per output block (MergeTreeDataPartWriterCompact.cpp:257), and a block tail shorter than a full granule gets its own short mark (:501-510, deliberate per the comment at :507). At 110 the 128-row merge emits 110 + 18 and writes 33 marks instead of 32, so the plan prints Granules: 17/33. merge_max_block_size is randomized, and was the one block-splitting setting not pinned beside index_granularity and index_granularity_bytes.

Not a server bug. At 110 the merge does not throw, force_data_skipping_indices = 'idx' raises no INDEX_NOT_USED, both counts are still 64, and idx still prunes half the granules. Only the exact-count literal moved; the invariant #119799 added this test for is intact.

The change pins merge_max_block_size = 8192, the setting's own default, in the table's SETTINGS clause; .reference and the assertion are unchanged. It is enforced, not best-effort: the client only injects a randomized MergeTree setting the clause does not already carry (ClientBase.cpp:3953). 49 other stateless tests pin it the same way.

Validation. Deterministic FAIL at 110 before, OK after; reverting only the pin brings the failure back. Swept 14 values from 1 to 8192 including all 7 predicted to break: green with the pin. 50/50 green, randomization confirmed live; the pin also suffices for Wide parts and vertical merges. CIDB: 832 passes against this one failure over 30 days, zero PR carriers.

7 other stateless tests assert an exact granule count after a merge without this pin; they measure 583k+ runs with zero master failures in the window, so I left them alone. Happy to extend the pin on request.

CIDB query and result (30 days, measured 2026-09-20)

```sql
SELECT if(pull_request_number = 0, 'master/release', 'PR') AS ref,
countIf(test_status = 'OK') AS ok,
countIf(test_status = 'SKIPPED') AS skipped,
countIf(test_status IN ('FAIL','ERROR')) AS fail,
uniqExact(commit_sha) AS shas
FROM default.checks
WHERE test_name = '05210_skip_index_type_from_alter_session_setting'
AND check_start_time > now() - INTERVAL 30 DAY
GROUP BY ref ORDER BY ref
```

| ref | ok | skipped | fail | shas |
|---|---|---|---|---|
| PR | 618 | 5 | 0 | 87 |
| master/release | 214 | 0 | 1 | 29 |

The single failing row: `Stateless tests (amd_tsan, parallel)`, `2026-09-19 23:37:18`, `ee32c21d2f6541c526f6d7fcef5062406aad7bd5`, `head_ref = master`, `pull_request_number = 0`.


Workflow [PR]
Sync PR [sync-upstream/pr/121126]
<!-- CI automatic block end :ci_links: -->

Comments Threads Pending Resolution

Resolved Comment Threads

No resolved comments have been left on this PR.