iframe-proxy

serxa · 2025-06-23T12:51:36Z

Changelog category (leave one):

New Feature

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

Introduce a memory reservation feature for workloads. More details https://clickhouse.com/docs/operations/workload-scheduling

Documentation entry for user-facing changes

Documentation is written (mandatory for new features)

Details

To enable memory reservations for workloads create MEMORY RESERVATION resource and set at least one limit for the total memory reserved using workload settings:

CREATE RESOURCE memory (MEMORY RESERVATION)
CREATE WORKLOAD all SETTINGS max_memory = '2Gi'

ClickHouse tracks memory allocations of all queries and background activities. The number of allocated bytes is aggregated through the scheduling hierarchy up to the root. Every query has an associated allocation in the leaf workload it belongs to. If a query has the reserve_memory setting greater than zero, then the allocation is created in a pending state. Pending allocation reserves requested amount of memory in the workload hierarchy. If there is not enough memory available, the allocation remains pending until enough memory is freed or other allocations are evicted (killed). When allocation is admitted, it becomes running. Running allocation could increase or decrease its size dynamically according to memory consumption of the query. Allocation life-cycle can be depicted with the following state diagram:

stateDiagram-v2
    [*] --> Pending: init [reserve_memory > 0]
    [*] --> Running: init [reserve_memory == 0]

    Pending --> Running: admit

    state Running {
        %% Region 1: increase flow
        NotIncreasing --> Increasing: request
        Increasing --> NotIncreasing: approve

        --

        %% Region 2: decrease flow
        NotDecreasing --> Decreasing: request
        Decreasing --> NotDecreasing: approve
    }


    Running --> Killed: evict
    Running --> Released: finish

Pending allocations of a leaf workload are admitted according to FIFO order. When multiple workloads have pending allocations, they are admitted according to precedence and weight settings. Higher precedence workloads are served first. Sibling workloads with the same precedence share memory according to weights in a max-min fair manner, which means that workload with lower normalized memory usage (current usage plus requested increase divided by weight) is served first. The reverse logic is applied during eviction. When memory needs to be freed, workloads with lower precedence and higher normalized memory usage are evicted first.

Note that time-shared resources use priority, while space-shared resources use precedence. They are independent settings and could be set to different values. Higher priority implies non-destructive preemption (delay or throttling), while higher precedence may imply destructive eviction (stops with an error). A workload could have high priority for CPU scheduling, but the same precedence for memory reservation to avoid evicting other workloads and losing work that was already done by them.

Every workload with a max_memory limit ensures that the total memory allocated in its subtree does not exceed the limit. If a pending or increasing allocation would exceed the limit, eviction procedure is initiated to free memory. Eviction procedure selects a victim to be killed. The least common ancestor workload of killer and victim prevents eviction in the following situations:

Pending allocation cannot evict running allocations in the same workload. (Killer and victim workloads coincide).
Pending allocation of lower precedence never kills workload of higher precedence.
Pending allocation cannot kill an allocation of the same precedence. Note that running allocations of the same precedence may evict each other based on normalized memory usage.
If eviction is prevented or does not free enough memory, the new allocation is blocked until enough memory is freed. These rules allow queueing of excessive queries based on memory pressure and provide a convenient way to avoid MEMORY_LIMIT_EXCEEDED errors.

NOTE: Workload limits are independent from other ways to limit memory consumption like max_memory_usage query setting. They could be used together to achieve better control over memory consumption. It is possible to set independent memory limits based on users (not workloads). This is less flexible and does not provide features like memory reservation and queueing of pending queries. See Memory overcommit

Workload setting max_waiting_queries limits the number of pending allocations for the workload. When the limit is reached, the server returns an error SERVER_OVERLOADED.

Memory reservation scheduling is not supported for merges and mutations yet.

Only queries with the reserve_memory setting greater than zero are subject to blocking while waiting for memory reservation. However, queries with zero reserve_memory are also accounted for in their workload memory footprint, and they can be evicted if necessary to free memory for other pending or increasing allocations. Queries without proper workload markup are not subject to memory reservation scheduling and cannot be evicted by the scheduler.

To provide non-elastic memory reservation for a query, set both reserve_memory and max_memory_usage query settings to the same value. In this case, the query will reserve fixed amount of memory and will not be able to increase its allocation dynamically.

Let's consider an example of configuration:

CREATE RESOURCE memory (MEMORY RESERVATION)
CREATE WORKLOAD all SETTINGS max_memory = '10Gi'
CREATE WORKLOAD system IN all SETTINGS weight = 1
CREATE WORKLOAD user IN all SETTINGS weight = 9
CREATE WORKLOAD production IN user SETTINGS precedence = 1, weight = 3
CREATE WORKLOAD staging IN user SETTINGS precedence = 1, weight = 1
CREATE WORKLOAD testing IN user SETTINGS precedence = 2

In this example, the total memory reserved by all queries and background activities cannot exceed 10 GiB. The system workload has a guarantee of at least 1 GiB (10% of 10 GiB), while the user workload has a guarantee of at least 9 GiB (90% of 10 GiB). Inside the user workload, production and staging workloads share memory according to weights (3 to 1) with equal precedence of 1. Testing workload has precedence 2, which is lower than production and staging. Therefore, testing workload can only use memory that is not used by production and staging.

If memory pressure arises, testing workload allocations will be evicted first. Then, if more memory needs to be freed, staging workload allocations will be evicted before production workload allocations if they exceed their guarantees. Note that pending queries in production and staging can evict running allocations in testing workload to free memory, but they cannot evict each other because they have the same precedence. In case of memory pressure, they will wait in queues, which allows the system to avoid MEMORY_LIMIT_EXCEEDED errors due to too many concurrently executing queries.

Note that system workload has precedence 0 (default), which is higher than production, staging and testing workloads, but they are not sibling workload. The least common ancestor is workload all, both children of which has equal precedence. So pending system workload cannot evict any of them, and vice versa. This ensures that system activities cannot easily be evicted.

Version info

Merged into: 26.6.1.1190
Backported to: 26.6.2.5

clickhouse-gh · 2025-06-23T12:52:03Z

Workflow [PR], commit [5fa163f]

Summary: ✅

Performance Comparison: Performance dashboard

AI Review

Summary

This PR introduces opt-in workload memory reservations by adding space-shared scheduler nodes, query MemoryReservation tracking, MEMORY RESERVATION resources, docs, metrics, and tests. The feature is still not safe to merge: current code has several scheduler/query-lifecycle paths that can leave queries stuck, account memory below the documented max_memory limit, or diverge storage from the running scheduler.

Findings

❌ Blockers

[src/Common/Scheduler/MemoryReservation.cpp:204] killAllocation only records kill_reason and notifies threads already inside MemoryReservation; it does not cancel or wake the victim query. If the selected victim is blocked in processor/IO wait, or has finished execution while still holding output/pipeline memory, it may never call syncWithMemoryTracker again, so the killer increase can wait indefinitely. Wire eviction into query cancellation/wakeup while preserving MEMORY_RESERVATION_KILLED for the victim.
[src/Interpreters/ProcessList.cpp:163] Initial memory admission can block before QueryStatus exists and before insertion into ProcessList. A query waiting for reserve_memory is invisible to system.processes, cannot be found by KILL QUERY, and is not registered with CancellationChecker, so it can wait indefinitely. Register a cancellable visible query status before the wait, or pass a cancellation token into the reservation wait.
[src/Common/Scheduler/MemoryReservation.cpp:168] Dynamic memory increases can also wait without observing user cancellation, max_execution_time, or client disconnect. cancelQuery only cancels registered executors and does not notify the MemoryReservation condition variable, so executor resources and the existing reservation can remain parked behind scheduler pressure. Include a cancellation predicate/token in both reservation waits and notify it from query/executor cancellation.
[src/Common/Scheduler/MemoryReservation.cpp:134] syncWithMemoryTracker can finish with no request in flight while allocated_size still differs from actual_size. Concurrent decrease/increase approval order can leave a waiter blocked forever, and the unchanged-tracker early return can leave stale over-reservation after an async decrease. Drive scheduling from actual_size versus allocated_size after each completion, or serialize decreases with increases until the reservation converges.
[src/Common/Scheduler/Nodes/SpaceShared/AllocationQueue.cpp:221] updateMinMaxAllocated propagates the next increase while still holding AllocationQueue::mutex; if the parent limit needs victim selection, it re-enters AllocationQueue::selectAllocationToKill and deadlocks on the same mutex. Decide whether the increase pointer changed under the lock, release the lock, then propagate.
[src/Common/Scheduler/Nodes/SpaceShared/AllocationQueue.cpp:436] updateQueueLimit has the same lock-order bug when trimming pending allocations exposes another over-limit increase, so a max_waiting_queries update can deadlock the scheduler thread. Use the same unlock-before-propagate pattern.
[src/Common/Scheduler/WorkloadResourceManager.cpp:140] DROP WORKLOAD detaches the leaf queue, but old classifier versions can still hold a raw ResourceLink to it. A later request through that old classifier can enqueue into a detached queue whose activation cannot reach the scheduler root, so the query waits forever instead of failing. Purge or mark deleted leaf queues unusable before detaching/destroying the workload node.
[src/Interpreters/executeQuery.cpp:2602] and [src/QueryPipeline/BlockIO.cpp:86] releaseWorkloadResources resets memory_reservation before all query-owned buffers, callbacks, exception formatting, and pipeline finalization are done. The scheduler can admit another query under max_memory while memory from the previous query is still live. Split early QuerySlot release from MemoryReservation release and keep the latter until query memory teardown is complete.
[src/Processors/Executors/PipelineExecutor.cpp:492] Memory accounting is synced only at pipeline executor safe points. Planning/interpreter allocations before the first processor step, and query paths that never enter a pipeline, can bypass workload max_memory accounting indefinitely. Add sync points around planning/no-pipeline paths, or require an upfront reservation for workload-memory-accounted queries.
[src/Common/Scheduler/Nodes/SpaceShared/FairAllocation.cpp:222] Zero-reserve allocations start as running locally but are not counted in parent running_children until their first Initial increase is approved. Under fair_allocation or precedence_allocation, an over-limit first growth can have no selectable victim and then wait forever instead of killing/failing the query. Make Initial increases selectable as victims or fail them before propagating above the leaf.
[src/Common/Scheduler/Nodes/SpaceShared/AllocationLimit.cpp:35] Lowering max_memory below current usage does not enforce the new hard limit unless a later increase happens. Existing allocations can remain over the new limit indefinitely. Trigger eviction from the limit update itself, or reject/serialize such updates.
[src/Common/Scheduler/Workload/WorkloadEntityStorageBase.cpp:719] setLocalEntities still bypasses the SQL validation for root uniqueness, references, duplicate resource roles, and workload settings. If config/Keeper publishes an invalid merged state, storage mutates entities and role-name fields before subscribers run; subscriber failure is only logged, leaving storage and WorkloadResourceManager diverged. Validate the merged target state before mutation, or make subscriber failure roll back/fail the refresh.

⚠️ Majors

[src/Storages/System/StorageSystemScheduler.cpp:35] The system.scheduler schema changes incompatibly: old monitoring columns become Nullable, and precedence is inserted before existing columns. Preserve old column order/types and append memory-specific columns, or explicitly document this as a backward-incompatible system-table change.
[docs/en/operations/system-tables/scheduler.md:21] The system.scheduler documentation is stale: it omits precedence, rejected_*, and the space-shared allocation columns, and still documents old non-Nullable columns. Regenerate/update the docs in this PR.
[docs/en/operations/workload-scheduling.md:428] The documented space-shared type names limit and queue do not match system.scheduler.type, where code exposes allocation_limit and allocation_queue. Use the actual type strings or change the code to expose the documented names consistently.
[docs/en/operations/workload-scheduling.md:120] The page uses max_memory_ratio in examples but omits it from the workload settings list. Add its semantics next to max_memory, including how it combines with exact limits and which memory amount it is based on.
[docs/en/operations/workload-scheduling.md:255] [dismissed by author -- https://github.com/ClickHouse/ClickHouse/pull/82414#discussion_r3336765833] The docs still say the memory hierarchy covers "all queries and background activities" and later the example says background activities cannot exceed 10 GiB, but code only creates MemoryReservation from non-internal query insertion and the same section says merges/mutations are unsupported. This still over-promises enforcement for background memory.

Tests

⚠️ Add focused regressions for the scheduler deadlocks in updateMinMaxAllocated and updateQueueLimit, cancellation while waiting for initial and dynamic memory reservation, zero-reserve first growth under fair_allocation/precedence_allocation, lowering max_memory below current usage, invalid config/Keeper refreshes, and no-pipeline/planning memory allocations.

Final Verdict

Status: ❌ Block

Minimum required actions: fix the blocker-level scheduler/query-lifecycle issues, update the system.scheduler schema/docs story, and add focused regressions for the deadlock, cancellation, limit-update, and accounting gaps.

clickhouse-gh · 2025-08-26T13:19:32Z

Dear @serxa, this PR hasn't been updated for a while. Will you continue working on it? If not, please close it. Otherwise, ignore this message.

clickhouse-gh · 2025-10-28T13:19:27Z

Dear @serxa, this PR hasn't been updated for a while. Will you continue working on it? If not, please close it. Otherwise, ignore this message.

…rces

…g workloads

serxa · 2026-06-23T16:52:18Z

@groeneai Take a look at this sanitizer report instead https://pastila.nl/?00062084/8f590dc0fb9d680da6000067dfaa5f03#g8N75wFB3bJ0yP06nI3wLg==GCM

…irness under sanitizers

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

groeneai · 2026-06-23T17:47:39Z

@serxa Not caused by this PR, and not yet fixed. It is a pre-existing data race in the MVCC transaction code that the server-side AST fuzzer surfaces; it is unrelated to the scheduler changes here.

What the report shows: a TSan race on Context::merge_tree_transaction (a shared_ptr<MergeTreeTransaction>, Context.h:696).

Read side (Restore_MakeTbl thread): RestorerFromBackup::createTable -> Context::createCopy (Context.cpp:1368, holds SharedLockGuard(other->mutex)) -> ContextData copy ctor reads merge_tree_transaction (Context.cpp:1316).
Write side (TCPHandler thread): executeASTFuzzerQueries (executeQuery.cpp:2114) -> Context::setCurrentTransaction (Context.cpp:7543) does merge_tree_transaction = std::move(txn) with no lock. getCurrentTransaction (Context.cpp:7548) is lock-free too.

Root cause: asymmetric locking. The copy path takes Context::mutex (shared), but setCurrentTransaction/getCurrentTransaction take no lock, so the reader's shared lock guards nothing. Any concurrent createCopy(ctx) racing a setCurrentTransaction(ctx, ...) on the same Context is a data race.

Why it is not this PR:

The only change here to Context.cpp and executeQuery.cpp is the releaseQuerySlot -> releaseWorkloadResources rename. No transaction code is touched.
git blame: the write (setCurrentTransaction) is from 2021, the copied member from 2024, the createCopy shared-lock from 2021-2023; the fuzzer transaction-reset block is from Feb-Mar 2026. None of it is on this branch (branch-only commits to both files are all Merge origin/master).
CIDB confirms it is a pre-existing master flake: this shared_ptr<MergeTreeTransaction> race has 133 hits across 55 distinct PRs and master in the last 30 days, and it fires on master itself, e.g. Stress test (amd_tsan) today (2026-06-23 15:14): https://s3.amazonaws.com/clickhouse-test-reports/json.html?REF=master&sha=1b07609e1a8d36ac9770f32da77a56285ed965e4&name_0=MasterCI&name_1=Stress%20test%20%28amd_tsan%29 and BuzzHouse (amd_tsan) on 2026-06-16: https://s3.amazonaws.com/clickhouse-test-reports/json.html?REF=master&sha=b4cb7ca1d2d361666630c565f4df7be8bd9e69a7&name_0=MasterCI&name_1=BuzzHouse%20%28amd_tsan%29 . Workload scheduling: Memory reservations #82414 itself only shows 3 hits over 18 days. No existing issue or fix PR.

Fix direction (for the transaction owners, not this PR): make access to merge_tree_transaction symmetric, i.e. take Context::mutex in setCurrentTransaction/getCurrentTransaction as well, or otherwise serialize Context copy vs transaction mutation. There is a hot-path consideration on getCurrentTransaction, so the exact locking granularity is a call for the transaction maintainers (cc the MVCC area). I did not push anything here since it is outside this PR and needs a TSan repro plus owner sign-off. I can open a tracking issue with this analysis if you want.

Base max_memory_ratio on total_memory_tracker.getHardLimit() so that max_server_memory_usage (and its derived RAM ratio) is respected, falling back to physical memory only when no server hard limit is configured. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

clickhouse-gh · 2026-06-23T18:07:26Z

+
+    // Update increase pointer in case the removed allocation was the current one
+    if (setIncrease() && parent)
+        propagate(Update().setIncrease(increase));


updateMinMaxAllocated still holds AllocationQueue::mutex when it propagates the new increase upward. That can deadlock the scheduler thread if the new current increase also needs eviction: e.g. one running allocation of 10, pending P1=30, pending P2=20, then max_memory is lowered to 25. This method rejects P1, makes P2 current, and calls propagate under the lock; AllocationLimit::setIncrease sees 10 + 20 > 25, calls selectAllocationToKill, and recurses back into AllocationQueue::selectAllocationToKill, which tries to take the same mutex.

Please collect whether the increase pointer changed while holding the lock, release the mutex, and only then propagate the update, or otherwise ensure victim selection cannot re-enter the same queue while its mutex is held.

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

clickhouse-gh · 2026-06-23T18:22:14Z

+
+    // Update increase pointer in case the removed allocation was the current one
+    if (setIncrease() && parent)
+        propagate(Update().setIncrease(increase));


updateQueueLimit can re-enter this same queue while AllocationQueue::mutex is still held. A concrete path is: lowering max_waiting_queries rejects the front pending allocation, setIncrease exposes the next pending/increasing request, then this propagate call reaches AllocationLimit::setIncrease; if the new request is still over max_memory, victim selection calls back into AllocationQueue::selectAllocationToKill, which tries to lock mutex again and deadlocks the scheduler thread.

Please follow the same pattern needed for updateMinMaxAllocated: decide whether the increase pointer changed while holding the lock, release mutex, and only then propagate the update upward.

azat · 2026-06-23T18:47:11Z

It will not turn itself without some "admin-level" CREATE RESOURCE memory (MEMORY RESERVATION). And I dont think we need to mark query setting reserve_memory with experimental_ prefix because we have this switch. So it is at least safe to release. And yes, I consider it experimental. What is the best way to reflect it?

Probably indeed some server-side experimental settings, not sure does it make sense to add some basic just for workflows (non-experimental)

clickhouse-gh · 2026-06-23T22:47:04Z

LLVM Coverage Report

Changed lines: Changed C/C++ lines covered by tests: 3491/3740 (93.34%) | Lost baseline coverage (was covered on master, now uncovered in this PR): 9 line(s) · Uncovered code

Full report · Diff report

Add changelog entries for PRs that landed on the 26.6 release line after the first pass: #82414, #108042 (New Feature), #107428 (Improvement), and #108128, #108288, #100205, #108029 (Bug Fix). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Cherry pick #82414 to 26.6: Workload scheduling: Memory reservations

Backport #82414 to 26.6: Workload scheduling: Memory reservations

rework scheduling nodes to support size-based allocations

f550d33

serxa marked this pull request as draft June 23, 2025 12:52

serxa changed the title ~~[WIP~~ [WIP] Workload memory scheduling Jun 23, 2025

serxa changed the title ~~[WIP] Workload memory scheduling~~ [WIP] Workload scheduling: memory reservations Jun 24, 2025

serxa changed the title ~~[WIP] Workload scheduling: memory reservations~~ [WIP] Workload scheduling: Memory reservations Jun 24, 2025

serxa mentioned this pull request Aug 3, 2025

[Umbrella] Workload Scheduling #84976

Open

29 tasks

Merge branch 'master' into workload-memory-scheduling

eddea07

serxa added 5 commits November 11, 2025 17:04

Major rework of the scheduler subsystem to support space-shared resou…

95de350

…rces

fix unit tests build

f3e9b6e

fix construction of WorkloadNode

759ecf1

name unit test files properly

a3c3ad8

Merge branch 'master' into workload-memory-scheduling

e005772

clickhouse-gh Bot added the pr-feature Pull request with new product feature label Nov 11, 2025

serxa added 2 commits November 13, 2025 19:46

Merge branch 'master' into workload-memory-scheduling

6869d3a

tests and bugfixes

89e3dc5

azat self-assigned this Nov 16, 2025

serxa added 11 commits November 17, 2025 13:05

fix: proper max-min fairness - use allocted + increase.size as key

30203c2

fix: pending allocation canceling logic, add tests

3361fe4

refactoring: split AllocationQueue into source and header files

f6f4855

refactoring: split AllocationLimit into source and header files

6e7fac0

test: proper ordering of request approvals

9647e43

add new space-shared scheduler node FairAllocation

aafacef

fix arm build

f5e41f9

fix: style

5fa3aaa

test: fair ordering of increases and pending allocations among siblin…

98a1c3c

…g workloads

Merge branch 'master' into workload-memory-scheduling

f07c127

test: max-min fairness with weights among sibling workloads

7bdb126

serxa and others added 3 commits June 23, 2026 17:13

do not run heavy-load test_scheduler_cpu_preemptive::test_cpu_time_fa…

3c76b1f

…irness under sanitizers

Add architecture overview diagram to MemoryReservation

7995500

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

Mark memory reservation scheduling as experimental

b940ce2

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

clickhouse-gh Bot reviewed Jun 23, 2026

View reviewed changes

Document dynamic nature of max_memory_ratio with TODO

5fa163f

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

clickhouse-gh Bot reviewed Jun 23, 2026

View reviewed changes

serxa enabled auto-merge June 23, 2026 22:15

serxa added this pull request to the merge queue Jun 24, 2026

Merged via the queue into master with commit a4e0784 Jun 24, 2026
166 of 167 checks passed

serxa deleted the workload-memory-scheduling branch June 24, 2026 00:51

robot-ch-test-poll added the pr-synced-to-cloud The PR is synced to the cloud repo label Jun 24, 2026

serxa mentioned this pull request Jun 24, 2026

Fix data race on MemoryReservation release at query finish #108391

Merged

Ergus mentioned this pull request Jun 24, 2026

Text index postprocessor #98939

Merged

serxa added the v26.6-must-backport label Jun 27, 2026

robot-ch-test-poll added the pr-must-backport-synced The `*-must-backport` labels are synced into the cloud Sync PR label Jun 27, 2026

robot-clickhouse-ci-2 mentioned this pull request Jun 27, 2026

Cherry pick #82414 to 26.6: Workload scheduling: Memory reservations #108686

Merged

robot-clickhouse-ci-2 added a commit that referenced this pull request Jun 27, 2026

Merge pull request #108686 from ClickHouse/cherrypick/26.6/82414

abd8c64

Cherry pick #82414 to 26.6: Workload scheduling: Memory reservations

robot-clickhouse added a commit that referenced this pull request Jun 27, 2026

Backport #82414 to 26.6: Workload scheduling: Memory reservations

2098704

robot-clickhouse-ci-2 mentioned this pull request Jun 27, 2026

Backport #82414 to 26.6: Workload scheduling: Memory reservations #108687

Merged

robot-ch-test-poll4 added the pr-backports-created Backport PRs are successfully created, it won't be processed by CI script anymore label Jun 27, 2026

clickhouse-gh Bot added a commit that referenced this pull request Jun 27, 2026

Merge pull request #108687 from ClickHouse/backport/26.6/82414

725640e

Backport #82414 to 26.6: Workload scheduling: Memory reservations

serxa mentioned this pull request Jul 1, 2026

[RFC] Reclaimable memory and dynamic spilling on top of memory reservations #109064

Open

alexey-milovidov mentioned this pull request Jul 2, 2026

Compress hash join right-side blocks in memory before OOM / spilling #107667

Open

1 task

Sunbelt Computer Software

PL/B Language Development and Support

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Workload scheduling: Memory reservations#82414

Workload scheduling: Memory reservations#82414
serxa merged 186 commits into
masterfrom
workload-memory-scheduling

serxa commented Jun 23, 2025 •

edited by robot-clickhouse-ci-1

Loading

Uh oh!

clickhouse-gh Bot commented Jun 23, 2025 •

edited

Loading

Uh oh!

clickhouse-gh Bot commented Aug 26, 2025

Uh oh!

clickhouse-gh Bot commented Oct 28, 2025

Uh oh!

serxa commented Jun 23, 2026

Uh oh!

groeneai commented Jun 23, 2026

Uh oh!

clickhouse-gh Bot Jun 23, 2026

Uh oh!

clickhouse-gh Bot Jun 23, 2026

Uh oh!

azat commented Jun 23, 2026

Uh oh!

clickhouse-gh Bot commented Jun 23, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Sunbelt Computer Software

PL/B Language Development and Support

Uh oh!

Conversation

serxa commented Jun 23, 2025 • edited by robot-clickhouse-ci-1 Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changelog category (leave one):

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

Documentation entry for user-facing changes

Details

Version info

Uh oh!

clickhouse-gh Bot commented Jun 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

AI Review

Summary

Findings

Tests

Final Verdict

Uh oh!

clickhouse-gh Bot commented Aug 26, 2025

Uh oh!

clickhouse-gh Bot commented Oct 28, 2025

Uh oh!

serxa commented Jun 23, 2026

Uh oh!

groeneai commented Jun 23, 2026

Uh oh!

clickhouse-gh Bot Jun 23, 2026

Choose a reason for hiding this comment

Uh oh!

clickhouse-gh Bot Jun 23, 2026

Choose a reason for hiding this comment

Uh oh!

azat commented Jun 23, 2026

Uh oh!

clickhouse-gh Bot commented Jun 23, 2026

LLVM Coverage Report

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

serxa commented Jun 23, 2025 •

edited by robot-clickhouse-ci-1

Loading

clickhouse-gh Bot commented Jun 23, 2025 •

edited

Loading