Fix stupid bug

This commit is contained in:
alesapin 2021-07-29 14:54:36 +03:00
parent bdc6858801
commit 5799487caa

View File

@ -2395,7 +2395,7 @@ MergeTreeData::DataPartsVector MergeTreeData::removePartsInRangeFromWorkingSet(c
/// It's a DROP PART and it's already executed by fetching some covering part
bool is_drop_part = !drop_range.isFakeDropRangePart() && drop_range.min_block;
if (is_drop_part && (part->info.min_block != drop_range.min_block || part->info.getDataVersion() != drop_range.getDataVersion()))
if (is_drop_part && (part->info.min_block != drop_range.min_block || part->info.max_block != drop_range.max_block || part->info.getDataVersion() != drop_range.getDataVersion()))
{
/// Why we check only min and max blocks here without checking merge
/// level? It's a tricky situation which can happen on a stale
@ -2411,7 +2411,8 @@ MergeTreeData::DataPartsVector MergeTreeData::removePartsInRangeFromWorkingSet(c
/// to drop all_2_2_2 after that it will receive the LOGICAL ERROR.
/// So here we just check that all_1_3_1 covers blocks from drop
/// all_2_2_2.
bool is_covered_by_min_max_block = part->info.min_block <= drop_range.min_block && part->info.getDataVersion() >= drop_range.getDataVersion();
///
bool is_covered_by_min_max_block = part->info.min_block <= drop_range.min_block && part->info.max_block >= drop_range.max_block && part->info.getDataVersion() >= drop_range.getDataVersion();
if (is_covered_by_min_max_block)
{
LOG_INFO(log, "Skipping drop range for part {} because covering part {} already exists", drop_range.getPartName(), part->name);