Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix order of ranges in MergeTreeDataSelectExecutor #9050

Merged
merged 3 commits into from
Feb 11, 2020

Conversation

CurtizJ
Copy link
Member

@CurtizJ CurtizJ commented Feb 7, 2020

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en

Changelog category (leave one):

  • Bug Fix

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

Fix order of ranges while reading from MergeTree table in one thread. It could lead to exceptions from MergeTreeRangeReader or wrong query results.

Fixes #8964.

@CurtizJ CurtizJ added the pr-bugfix Pull request with bugfix, not backported by default label Feb 7, 2020
@CurtizJ
Copy link
Member Author

CurtizJ commented Feb 7, 2020

Actually the mistake was that here ranges were passed to MergeTreeSelectProcessor in reversed order, while it expected them in direct order. Previosly ranges were reversed here.

@@ -251,6 +240,10 @@ void MergeTreeReadPool::fillPerThreadInfo(
{
threads_tasks.resize(threads);

/// Let the ranges be listed from right to left so that the leftmost range can be dropped using `pop_back()`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the only reason to reverse the array is to have O(1) deletion, we can just use std::deque.

Copy link
Member Author

@CurtizJ CurtizJ Feb 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we can. Actually I don't know why originally std::vector was used.

@alesapin
Copy link
Member

Actually the mistake was that here ranges were passed to MergeTreeSelectProcessor in reversed order, while it expected them in direct order. Previosly ranges were reversed here.

Seems like single-threaded read order was broken here too.
#9048

@alexey-milovidov alexey-milovidov mentioned this pull request Feb 10, 2020
16 tasks
@CurtizJ
Copy link
Member Author

CurtizJ commented Feb 10, 2020

This and this lines also look like bugs, because we want to get rest of the marks starting from the most left, but pass the most right mark as them were reversed. Now, it's ok without changing these lines.

@qoega qoega merged commit 5b4b04e into ClickHouse:master Feb 11, 2020
alexey-milovidov added a commit that referenced this pull request Feb 19, 2020
abyss7 pushed a commit that referenced this pull request Feb 21, 2020
Fix order of ranges in MergeTreeDataSelectExecutor

(cherry picked from commit 5b4b04e)
abyss7 pushed a commit that referenced this pull request Feb 21, 2020
Fix mistake introduced in #9050.

(cherry picked from commit 1c66c2f)
@abyss7 abyss7 added the v20.1 label Feb 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr-bugfix Pull request with bugfix, not backported by default
Projects
None yet
Development

Successfully merging this pull request may close these issues.

DB::Exception: RangeReader read 7523 rows, but 7550 expected..
5 participants