[jira] [Commented] (KUDU-3384) DRS-level scan optimization leads to failed scans

["Alexey Serbin (Jira)" <ji...@apache.org>]

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

Alexey Serbin commented on KUDU-3384:
-------------------------------------

Backtrace from lldb when enabling the newly added test in http://gerrit.cloudera.org:8080/18757:

{noformat}
* thread #146, name = 'rpc worker-30047859', stop reason = breakpoint 1.1
    frame #0: 0x000000010c0dfeb3 libkudu_common.dylib`kudu::EncodedKey::IncrementEncodedKey(tablet_schema=0x00000001116efb18, key=0x000070000ade08a8, arena=0x0000000110a71e98) at encoded_key.cc:93:33
   90  	  // Increment the new key
   91  	  ContiguousRow new_row(&tablet_schema, new_row_key);
   92  	  if (!key_util::IncrementPrimaryKey(&new_row, arena)) {
-> 93  	    return Status::IllegalState("No lexicographically greater key exists");
   94  	  }
   95  	
   96  	  // Re-encode it.
Target 0: (flex_partitioning_client-test) stopped.
(lldb) bt
* thread #146, name = 'rpc worker-30047859', stop reason = breakpoint 1.1
  * frame #0: 0x000000010c0dfeb3 libkudu_common.dylib`kudu::EncodedKey::IncrementEncodedKey(tablet_schema=0x00000001116efb18, key=0x000070000ade08a8, arena=0x0000000110a71e98) at encoded_key.cc:93:33
    frame #1: 0x0000000106184909 libtablet.dylib`kudu::tablet::CFileSet::Iterator::OptimizePKPredicates(this=0x0000000110a71e10, spec=0x0000000110a70340) at cfile_set.cc:445:3
    frame #2: 0x000000010618433e libtablet.dylib`kudu::tablet::CFileSet::Iterator::Init(this=0x0000000110a71e10, spec=0x0000000110a70340) at cfile_set.cc:403:3
    frame #3: 0x000000010631c0a9 libtablet.dylib`kudu::tablet::DeltaApplier::Init(this=0x0000000110e29b80, spec=0x0000000110a70340) at delta_applier.cc:59:3
    frame #4: 0x000000010c0eefd2 libkudu_common.dylib`kudu::MaterializingIterator::Init(this=0x0000000110e20080, spec=0x0000000110a70340) at generic_iterators.cc:1173:3
    frame #5: 0x000000010c0e795e libkudu_common.dylib`kudu::InitAndMaybeWrap(base_iter=0x0000000112063040, spec=0x0000000110a70340) at generic_iterators.cc:1513:3
    frame #6: 0x000000010c0ed87f libkudu_common.dylib`kudu::UnionIterator::InitSubIterators(this=0x0000000110b070e0, spec=0x000070000ade1ea0) at generic_iterators.cc:1029:5
    frame #7: 0x000000010c0ed232 libkudu_common.dylib`kudu::UnionIterator::Init(this=0x0000000110b070e0, spec=0x000070000ade1ea0) at generic_iterators.cc:1002:3
    frame #8: 0x000000010604a79d libtablet.dylib`kudu::tablet::Tablet::Iterator::Init(this=0x00000001105e3a00, spec=0x000070000ade1ea0) at tablet.cc:3057:3
    frame #9: 0x0000000101f2b642 libtserver.dylib`kudu::tserver::TabletServiceImpl::HandleNewScanRequest(this=0x0000000110e83e00, replica=0x00000001112c3d40, req=0x000000011129c060, rpc_context=0x00000001115ccc20, result_collector=0x000070000ade27f0, scanner_id="", snap_timestamp=0x000070000ade2648, has_more_results=0x000070000ade267f, error_code=0x000070000ade2678) at tablet_service.cc:2938:15
    frame #10: 0x0000000101f2717e libtserver.dylib`kudu::tserver::TabletServiceImpl::Scan(this=0x0000000110e83e00, req=0x000000011129c060, resp=0x000000011129c3d8, context=0x00000001115ccc20) at tablet_service.cc:2210:16
{noformat}

> 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
>            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)