Comment 1 for bug 1395840

Looked at few cores for this bug and they all failed due to the same cause: at frame #6 ExHbaseAccess::keySubsetExeExpr_ was null.

The keySubsetExeExpr_ is constructed at the runtime based on ComTdbHbaseAccess::keyInfo_, but that field was null too.

executor/ExHbaseAccess.cpp:
    268 keySubsetExeExpr_ = NULL;
    269 keyMdamExeExpr_ = NULL;
    270 if (hbaseAccessTdb.keySubsetGen())
    271 {
    272 // this constructor will also do the fixups of underlying expressi ons
    273 keySubsetExeExpr_ = new(glob->getSpace())
    274 keySingleSubsetEx(*hbaseAccessTdb.keySubsetGen(),
    275 1, // version 1
    276 pool_,
    277 getGlobals(),
    278 getExpressionMode(), this);
    279 }

comexe/ComTdbHbaseAccess.h:
    472 keySingleSubsetGen * keySubsetGen() const
    473 {
    474 return
    475 (keyInfo_ && keyInfo_->castToKeySingleSubsetGen() ?
    476 keyInfo_->castToKeySingleSubsetGen() :
    477 NULL);
    478 }
    479

(gdb) p this->keySubsetExeExpr_
$1 = (keySingleSubsetEx *) 0x0

(gdb) p ((ComTdbHbaseAccess*)0x7fffbe4e6e58)->keyInfo_
$4 = {{ptr_ = 0x0, offset_ = 0}}

The query executed was like:
update TRAFODION.\"_MD_\".OBJECTS set catalog_name = 'TRAFODION', schema_name = 'ALTER_RENAME_RENAME21', object_name = 'TAB_EMP_NEW_01' where object_uid = 158802970814398584;

The objects meta data table has an index based on object_uid. If we use index in the plan, we should not use key subset scan.

Could this be a problem of inconsistent plan?