Repository navigation
Antalya 26.6 Backport of #128865 - Fix wrong ORDER BY results and pushed bucket twice with offset based parallel replicas - #2802
Conversation
…plicas-ordered-merges Fix wrong `ORDER BY` results and `pushed bucket twice` with offset based parallel replicas Conflicts committed as-is; the next commit resolves them: - src/Processors/QueryPlan/Optimizations/Optimizations.h (both modified) - src/Processors/QueryPlan/Optimizations/optimizeTree.cpp (both modified) - src/Processors/QueryPlan/ReadFromRemote.cpp (both modified) - src/Processors/QueryPlan/ReadFromRemote.h (both modified)
Added the PR's one-replica condition to antalya-26.6's existing GET_ONE/GET_MANY branch in `ReadFromRemote::addPipe`, and dropped unrelated upstream code that came in through the conflict hunks.
|
Backporter: cherry-pick conflicts resolved by AI Conflicted files:
Commits:
|
CI triage for 5f93e27Summary: 4 failing checks. 0 are caused by this PR, 1 is a process/metadata issue (DCO), and 3 are flaky or infra. The backport's own tests did not fail in any suite:
1. DCO: not a code problem, fix on this PRNeither commit has a sign-off:
Fix: if the repo requires DCO, add sign-offs. One way is 2. Stateless (amd_asan_ubsan, cas s3 storage, parallel, 1/2):
|
Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):
Fixed wrong results of
ORDER BY(unsorted rows, wrong rows underLIMIT) and theGroupingAggregatedTransform pushed bucket ... twiceerror (duplicated groups in older versions) of queries withparallel_replicas_mode = 'sampling_key', or a custom key mode on a cluster with more than one shard. Such a query now reads a shard from one replica unless the initiator only aggregates or fully sorts the parts returned by the replicas. (ClickHouse#128865 by @groeneai)Documentation entry for user-facing changes
...
CI/CD Options
Exclude tests:
Regression jobs to run: