Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ alexey-milovidov
❌ avoronov-explyt
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

Workflow [PR], commit [8d617d7]

Summary: ✅

• Performance Comparison: Performance dashboard

AI Review

Summary

This PR corrects embedded FunctionDocumentation examples for h3Distance, multiSearchFirstPositionUTF8, multiSearchFirstPositionCaseInsensitiveUTF8, and readWKTMultiLineString. I reviewed the current diff and prior review discussion against the checked-out source; the earlier Pretty block width issue is fixed, and I found no remaining high-signal correctness or documentation-contract issues.

Final Verdict

Status: ✅ Approve

Picked this up, merged master (was ~1688 behind, clean), and verified all four example outputs against a local server:

• h3Distance(590080540275638271, 590103561300344831) → 6 ✅
• multiSearchFirstPositionUTF8('Здравствуй, мир', ['мир', 'вст', 'авст']) → 4 ✅
• readWKTMultiLineString('MULTILINESTRING ((1 1, 2 2, 3 3, 1 1))') → MultiLineString ✅
• multiSearchFirstPositionCaseInsensitiveUTF8('Здравствуй, мир', ['МИР', 'вст', 'Здра']) → 1, not 3

The last one: the previous commit fixed only the result header case (мир → МИР) but kept the value 3, which is also wrong — the needle 'Здра' matches at position 1, so I corrected the example value to 1 (commit a13d3ea1ca0).

Also filled in the PR body's changelog category (Documentation), which was the only CI failure (Change category is missing or invalid).

@groeneai, the only CI failure is Tests/04277_parallel_replicas_join_dp_reorder with MEMORY_LIMIT_EXCEEDED (Code 241, current RSS: 53.70 GiB, maximum: 53.69 GiB) on the arm_asan_ubsan, azure, parallel shard. This is a docs-only PR (it only edits string literals inside embedded function-documentation blocks), so it cannot affect parallel-replicas JOIN memory usage. CIDB shows this test flaking sporadically on unrelated PRs over the last two weeks (#106734, #101398, #105889). Please investigate and provide a fix in a separate PR if one is not already in progress.

Report: https://s3.amazonaws.com/clickhouse-test-reports/json.html?PR=106175&sha=a13d3ea1ca0a364a5f27aa68875f066007db2c63&name_0=PR&name_1=Stateless%20tests%20%28arm_asan_ubsan%2C%20azure%2C%20parallel%29

@alexey-milovidov investigated. Short version: 04277_parallel_replicas_join_dp_reorder is one of many incidental victims of host-level RSS pressure on the arm_asan_ubsan, azure, parallel shard, not a test-specific issue.

What the failure looks like on this PR

Code: 241. (total) memory limit exceeded:
  would use 4.13 GiB (attempt to allocate chunk of 1.00 MiB),
  current RSS: 53.70 GiB, maximum: 53.69 GiB: While executing Remote.
(query 11, line 55: SELECT count() FROM pr_dp_a JOIN pr_dp_b ... JOIN pr_dp_c ...)

3/3 reruns passed. The test data itself is trivial — three MergeTree tables of 100, 1000, and 100000 rows, single UInt32 column. It cannot legitimately use 53 GiB; it is the query that loses the OvercommitTracker arbitration when the runner's cumulative RSS already sits at the cap.

Shard-wide picture (CIDB, last 14d on Stateless tests (arm_asan_ubsan, azure, parallel), current RSS: 53.69 GiB pattern)

• 50 unique tests hit, 60 total hits, 40 unique PRs
• Steady cadence: 1–16 hits/day, no master gap
• Top victims: 03742_nested_loop_join_long (5), 01603_read_with_backoff_bug (4), 03748_join_on_complex_condition_result_memory (3), 02455_one_row_from_csv_memory_usage (2), 04033_tpc_ds_q04/q11/q61 (2/1/1), 01661_extract_all_groups_throw_fast (2), and a long tail of single-hit incidental victims
• 04277_parallel_replicas_join_dp_reorder itself: 1 hit in 14d on this shard, all 3 reruns passed (this PR's run)

CIDB on 04277_parallel_replicas_join_dp_reorder (30d, all shards)

• 0 master hits
• 4 unique PRs total: Fix cardinality underestimation when join column NDVs are unknown #101398 (2× Fast test — author's own PR restore_join_step_estimation, result-order failures, not memory), More settings to randomize #106734 (1× amd_debug — BAD_ARGUMENTS from a CI randomization PR), Allow DP join reordering with parallel replicas #105889 (1× — result-order on a non-default exotic shard), and this one (fix(docs): correct h3Distance example output value #106175 — only RSS-OOM hit).

So the only RSS-OOM occurrence for 04277 is this single 0/3-rerun hit on this shard, and it is not even close to the worst victim there.

Precedent

The closest sibling case I have open is PR #106797 (filed yesterday under your earlier directive on PR #104545 — 04033_tpc_ds_q61): same shard, same OvercommitTracker arbitration, same current RSS: 53.7 GiB / 53.69 GiB shape. There I disabled the test mirroring the existing pattern for 04033_tpc_ds_q35. But q61 had multiple hits including blocking the parent PR's CI — 04277 does not (1 hit / 14d, 3/3 reruns clean).

Why I'm NOT speculatively pushing a 04277 disable / data shrink

Per past directives I'd be making a defensive change for a failure I can't reproduce locally and that has hit this test exactly once in 14 days. The test's data is already small; there is nothing to shrink. Disabling it just shifts the next victim of the same shard pressure to whichever query happens to lose the next OvercommitTracker arbitration. That doesn't address the systemic ~5 unique-test-hits/day issue.

What I'd like direction on

Two reasonable paths, both viable:

1. Mirror PR Disable 04033_tpc_ds_q61 (MEMORY_LIMIT_EXCEEDED on arm_asan_ubsan azure parallel) #106797 for 04277. Symmetric with 04033_tpc_ds_q61/q35. I can file the same one-line SKIP disable + comment if you want a quick stop-the-bleed for this specific test.
2. Treat as the chronic shard-wide host-RSS issue. Investigate why the runner's sanitizer + Azure + parallel triple is sitting at the 53.7 GiB cap (50 unique tests / 40 PRs over 14d argue for an environment fix or runner memory bump rather than per-test disables).

Please tell me which you'd prefer. Default would be (1) since you asked for a separate PR and that mirrors the precedent. CIDB report URL on this exact failure: https://s3.amazonaws.com/clickhouse-test-reports/json.html?PR=106175&sha=a13d3ea1ca0a364a5f27aa68875f066007db2c63&name_0=PR&name_1=Stateless%20tests%20%28arm_asan_ubsan%2C%20azure%2C%20parallel%29

Session: cron:clickhouse-ci-task-worker:20260609-040300

LLVM Coverage Report

Changed lines: Changed C/C++ lines covered by tests: 27/27 (100.00%) | Lost baseline coverage: none · Uncovered code

Full report · Diff report

@groeneai, investigate the failure: https://s3.amazonaws.com/clickhouse-test-reports/json.html?PR=106175&sha=8d617d769b286ed421c0f5cb29b803bbf8c0ef94&name_0=PR&name_1=Integration%20tests%20%28amd_msan%2C%204%2F6%29 and provide a fix in a separate PR. If the fix is already in progress, link it here.

The failure is test_profile_max_sessions_for_user/test.py::test_profile_max_sessions_for_user_postgres — a pytest timeout (>900 s) in threaded_run_test([postgres_session] * 3) on the amd_msan shard. This is unrelated to this PR: the PR only edits string literals inside embedded FunctionDocumentation blocks, and per CIDB this test has timed out on many unrelated PRs and on master over the last week (e.g. #106538, #95659, #106137, #101789, #106020, #102308, #106177, #96130), so it looks like a recurring flaky timeout of the PostgreSQL session test under MSan. There is no open issue for it yet. I have rerun the failed job in the meantime.

@alexey-milovidov Thanks for the rerun. Confirmed this is unrelated to the docs PR.

CIDB over 30 days: the timeout is specific to the postgres variant and to MSan. 14 timeouts on test_profile_max_sessions_for_user_postgres across 13 distinct PRs plus master (11 of 14 on amd_msan), versus 1 each for the tcp/http/mysql/grpc variants. Recurring flaky timeout, not a regression. No open issue or fix PR exists yet.

Preliminary root cause (confirming with a local repro before I open the fix):

threaded_run_test starts 3 postgres sessions (max_sessions_for_user=2), waits for the overflown session count log, then issues a single KILL QUERY WHERE user='test_user' SYNC and thread.join() with no timeout. That log fires at session acquisition (Session::trackSession), not at query execution, so it only proves the excess session was rejected. The two accepted sessions' SELECT ..., COUNT(*) FROM system.numbers (infinite) queries may not have reached the process list when the one-shot KILL runs. If a query starts after the KILL, nothing kills it and it runs forever. The postgres worker is psycopg2 with no client-side query timeout, so the thread blocks in fetchall() until the 900s pytest limit. The native-protocol variants have a 600s client timeout (helpers/client.py) that masks the same race, which is why postgres dominates. MSan widens the connect-to-execute window and raises the hit rate.

Fix direction (separate PR, per your request): make the cleanup robust against a late-starting query by killing in a loop until no test_user queries remain in system.processes (instead of a single one-shot KILL), bounded well under the pytest limit. The overflow assertion is unchanged. I will link the PR here.

@alexey-milovidov Fix is up in a separate PR: #107086

Confirmed the root cause locally: the single KILL QUERY WHERE user='test_user' SYNC in threaded_run_test snapshots system.processes once, but the overflown session count log it waits on is emitted at session acquisition, not at query execution. An accepted postgres session whose infinite SELECT registers after the KILL is never killed and its thread blocks until the 900s pytest timeout. Against a local debug server the current code hangs deterministically; the patched loop (re-issue KILL until all worker threads exit, thread-liveness driven, bounded 60s) joins everything within seconds.