[
https://issues.apache.org/jira/browse/KUDU-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17568895#comment-17568895
]
ASF subversion and git services commented on KUDU-3384:
-------------------------------------------------------
Commit 6fe47b5ecc5bdafdb17aa7722d296c4e5d4d32bf in kudu's branch
refs/heads/master from Alexey Serbin
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=6fe47b5ec ]
KUDU-3384 reproduction scenario
This patch contains a new test scenario to reproduce KUDU-3384.
The new test is disabled since it fails pretty reliably, at least
if built in DEBUG configuration.
Change-Id: Ib6c4d3384a788ac48a67f4aa203290a271a30867
Reviewed-on: http://gerrit.cloudera.org:8080/18757
Tested-by: Kudu Jenkins
Reviewed-by: Yifan Zhang <chinazhangyi...@163.com>
> DRS-level scan optimization leads to failed scans
> -------------------------------------------------
>
> Key: KUDU-3384
> URL: https://issues.apache.org/jira/browse/KUDU-3384
> Project: Kudu
> Issue Type: Bug
> Components: tserver
> Affects Versions: 1.17.0
> Reporter: Alexey Serbin
> Assignee: YifanZhang
> Priority: Major
>
> Recently, a new DRS-level optimization for scan operations has been
> introduced with changelist
> [936d7edc4|https://github.com/apache/kudu/commit/936d7edc4e4b69d2e1f1dffc96760cb3fd57a934].
> The newly introduced DRS-level optimization leads to scan failures when all
> of the following turns true:
> * all the primary key columns are of integer types
> * the table has no hash partitioning
> * the table contains a row with all primary key columns set to
> {{INT\{x}_MAX}} correspondingly
> * the scan request is to scan all the table's data
> I suspect that some of the conditions above might be relaxed, but I have a
> test case that reproduces the issue as described. See [this gerrit review
> item|http://gerrit.cloudera.org:8080/18757] for the reproduction scenario.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
