Dan Hecht has posted comments on this change. Change subject: IMPALA-2399: Check for mem limit in allocations in parquet scanner and decompressor ......................................................................
Patch Set 14: (3 comments) http://gerrit.cloudera.org:8080/#/c/2203/14/be/src/exec/base-sequence-scanner.cc File be/src/exec/base-sequence-scanner.cc: Line 95: DCHECK(prepared_ == (batch_ != NULL)); this doesn't look true -- what if StartNewRowBatch() takes the mem limit exceeded path? we'll have batch_ != NULL but !prepared_.. I think we need to write this in a way that doesn't make assumptions about the state of after Prepare() is called - there's too many paths to reason about. http://gerrit.cloudera.org:8080/#/c/2203/14/be/src/exec/hdfs-parquet-scanner.cc File be/src/exec/hdfs-parquet-scanner.cc: Line 1648: DCHECK_EQ(num_rows, 0); Why is this DCHECK interesting? i.e. why does the caller care about num_rows value at all if the function returns !ok()? http://gerrit.cloudera.org:8080/#/c/2203/14/be/src/runtime/collection-value.h File be/src/runtime/collection-value.h: Line 32: int64_t num_tuples; I think the frontend needs to know about this change. Maybe revert this change for now. -- To view, visit http://gerrit.cloudera.org:8080/2203 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ic70400407b7662999332448f4d1bce2cc344ca89 Gerrit-PatchSet: 14 Gerrit-Project: Impala Gerrit-Branch: cdh5-trunk Gerrit-Owner: Michael Ho <[email protected]> Gerrit-Reviewer: Dan Hecht <[email protected]> Gerrit-Reviewer: Michael Ho <[email protected]> Gerrit-Reviewer: Skye Wanderman-Milne <[email protected]> Gerrit-Reviewer: Tim Armstrong <[email protected]> Gerrit-HasComments: Yes
