Fix the shell's runtime profile test to be more robust.

This patch uses a regex rather than a raw string to search for unique query profiles in
the shell's output.

Change-Id: I5c0c2dc30ad6d9a14e5c35177f5a494445b7cc7c
Reviewed-on: http://gerrit.sjc.cloudera.com:8080/5381
Reviewed-by: Ishaan Joshi <ishaan@cloudera.com>
Tested-by: jenkins
IMPALA-1479: Downgrade severity of unknown query ID for report

The error message that was printed at INFO when a report is received for
an unknown query isn't really actionable, and can rapidly dominate a log
if there are many backends that are slow to tear down once a query is
finished. Any underlying problems with fragments continuing to run after
the query is finished should be detected through other means (e.g. the
debug webpage).

Change-Id: I156389f42a3fada1318020d4731c3da64793f7b1
Reviewed-on: http://gerrit.sjc.cloudera.com:8080/5378
Reviewed-by: Nong Li <nong@cloudera.com>
Reviewed-by: Henry Robinson <henry@cloudera.com>
Tested-by: Henry Robinson <henry@cloudera.com>
IMPALA-1508: don't JIT TimestampFunctions::DateAddSub

For some reason, the try/catch added to fix IMPALA-1493 doesn't work
when we JIT the function. Fixing this in the JIT'd code will take some
time, so for now just don't JIT the function.

Change-Id: I7b2801027db0a9deb19b477c1a4ca0bdad77a825
Reviewed-on: http://gerrit.sjc.cloudera.com:8080/5383
Reviewed-by: Skye Wanderman-Milne <skye@cloudera.com>
Tested-by: jenkins
IMPALA-1371: Predicate applied incorrectly when FULL OUTER JOIN is
present

This commit fixes the issue where predicates are not applied to the
correct query tree nodes when the query contains full outer joins. To
address this issue, we register information about the tuple ids that
are outer joined by full outer joins and use that information to guide
the assignment of predicates.

Change-Id: I854c05c159d86c0aaabfc12b7dd5c5982c5ece4b
Reviewed-on: http://gerrit.sjc.cloudera.com:8080/5284
Reviewed-by: Dimitris Tsirogiannis <dtsirogiannis@cloudera.com>
Tested-by: jenkins
IMPALA-1506: gzip compressor incorrectly sets output size

A bug was discovered where our gzip compression path did not correctly set the output
block size in all cases. It would appear this code has been erroneous for well over a year
and the issue just surfaced because the code path was not being used regularly.

Change-Id: I8da7415f2b3c558e33ab0c0ac53e907501806e83
Reviewed-on: http://gerrit.sjc.cloudera.com:8080/5379
Reviewed-by: Victor Bittorf <victor.bittorf@cloudera.com>
Tested-by: jenkins