[ 
https://issues.apache.org/jira/browse/IMPALA-8562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856812#comment-16856812
 ] 

ASF subversion and git services commented on IMPALA-8562:
---------------------------------------------------------

Commit e573b5502d4a93623dd1375e8e8febf9647c98db in impala's branch 
refs/heads/master from Michael Ho
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=e573b55 ]

IMPALA-8562: Data cache should skip insertion of uncacheable ScanRanges

As shown in IMPALA-8561, there are some paths in the code which
create uncacheable ScanRanges. These uncacheable ScanRanges have
mtime of -1. 'mtime' is used for differentiating versions of files
with the same names. An mtime == -1 means the cache entry could
potentially be from any versions of a file with the same name.

This change skips lookup or insertion of ScanRange with negative
mtime, file offset or buffer length.

Testing done: Added targeted test cases in data-cache-test

Change-Id: I2294833b075a2ddcae956d9fdb04f3e85adb0391
Reviewed-on: http://gerrit.cloudera.org:8080/13369
Reviewed-by: Impala Public Jenkins <[email protected]>
Tested-by: Impala Public Jenkins <[email protected]>


> Data cache should skip scan range with mtime == -1
> --------------------------------------------------
>
>                 Key: IMPALA-8562
>                 URL: https://issues.apache.org/jira/browse/IMPALA-8562
>             Project: IMPALA
>          Issue Type: Bug
>          Components: Backend
>    Affects Versions: Impala 3.3.0
>            Reporter: Michael Ho
>            Assignee: Michael Ho
>            Priority: Blocker
>
> As show in IMPALA-8561, using mtime == -1 as part of cache key may lead to 
> reading stale data. Data cache should probably just skip caching those 
> entries.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to