[
https://issues.apache.org/jira/browse/IMPALA-14462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18028160#comment-18028160
]
ASF subversion and git services commented on IMPALA-14462:
----------------------------------------------------------
Commit 762fe0a4f5c9089e8a75fd992ab39c85943db562 in impala's branch
refs/heads/master from Joe McDonnell
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=762fe0a4f ]
IMPALA-14473: Fix absolute path logic for sorting scan ranges oldest to newest
When IMPALA-14462 added tie-breaking logic to
ScanRangeOldestToNewestComparator, it relied on absolute path
being unset if the relative path is set. However, the code
always sets absolute path and uses an empty string to indicate
whether it is set. This caused the tie-breaking logic to see
two unrelated scan ranges as equal, triggering a DCHECK when
running query_test/test_tuple_cache_tpc_queries.py.
The fix is to rearrange the logic to check whether the relative
path is not empty rather than checking whether the absolute
path is set.
Testing:
- Ran query_test/test_tuple_cache_tpc_queries.py
- Ran custom_cluster/test_tuple_cache.py
Change-Id: I449308f4a0efdca7fc238e3dda24985a2931dd37
Reviewed-on: http://gerrit.cloudera.org:8080/23495
Reviewed-by: Michael Smith <[email protected]>
Tested-by: Impala Public Jenkins <[email protected]>
Reviewed-by: Yida Wu <[email protected]>
Reviewed-by: Joe McDonnell <[email protected]>
> TestTupleCacheFullCluster.test_scan_range_distributed fails on S3
> -----------------------------------------------------------------
>
> Key: IMPALA-14462
> URL: https://issues.apache.org/jira/browse/IMPALA-14462
> Project: IMPALA
> Issue Type: Bug
> Components: Backend, Test
> Affects Versions: Impala 5.0.0
> Reporter: Joe McDonnell
> Assignee: Joe McDonnell
> Priority: Blocker
> Fix For: Impala 5.0.0
>
>
> TestTupleCacheFullCluster.test_scan_range_distributed is expecting that
> inserting a single file doesn't change tuple cache's runtime hash for more
> than a single executor. This should be true due to the modification to
> schedule scan ranges oldest to newest. This is failing on S3:
> {noformat}
> custom_cluster/test_tuple_cache.py:905: in test_scan_range_distributed
> assert len(after_insert_unique_cache_keys - unique_cache_keys) == 1
> E assert 3 == 1
> E + where 3 = len(({'6e2682fb793acd7b689a8d69aab01675_1266802730',
> '6e2682fb793acd7b689a8d69aab01675_2730281323',
> '6e2682fb793acd7b689a8d69aab01675_3027502829'} -
> {'6e2682fb793acd7b689a8d69aab01675_1885657991',
> '6e2682fb793acd7b689a8d69aab01675_2939791479',
> '6e2682fb793acd7b689a8d69aab01675_3685468122'})){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
