Pull Request Overview
- Opened on September 20, 2026
- Status Open
- Commit count 0
Total Delta
Open Days
Test Delta
How long has this pull request spent in each phase of its lifecycle?
Data pending calculation for pull request
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.