Impala queries on large tables could take substantial time to process (serialize) the query plan. The amount of time varied based on the number of HDFS blocks in the table and the HDFS replication factor.

Bug: IMPALA-958

Severity: High

Occasionally, a non-trivial query run through Llama could encounter a serious error. The detailed error in the log was:

boost::exception_detail::clone_impl
  <boost::exception_detail::error_info_injector<boost::lock_error> >

Severity: High

Impala log files could contain internal error messages due to a problem formatting certain strings. The messages consisted of a Java call stack starting with:

jni-util.cc:177] java.util.MissingFormatArgumentException: Format specifier 's'

Severity: High

A downlevel version of the HiveServer 2 API could cause difficulty retrieving the precision and scale of a DECIMAL value.

Bug: IMPALA-1107

Severity: High

The error in the title could occur following a DDL statement. This issue was discovered during internal testing and has not been reported in customer environments.

Bug: IMPALA-1093

Severity: High

The time for some network operations was not counted in the report of total time for a query, making it difficult to diagnose network-related performance issues.

Bug: IMPALA-1131

Severity: High

Certain Avro fields for byte data could cause Impala to be unable to read an Avro data file, even if the field was not part of the Impala table definition. With this fix, Impala can now read these Avro data files, although Impala queries cannot refer to the "bytes" fields.

Bug: IMPALA-1149

Severity: High

The --authorization_policy_provider_class option for impaladwas added back. This option specifies a custom AuthorizationProvider class rather than the default HadoopGroupAuthorizationProvider. It had been used for internal testing, then removed in Impala 1.4.0, but it was considered useful by some customers.

Bug: IMPALA-1142

Severity: High

The serious error in the title could occur, with the supplemental message:

num_used_buffers_ < 0: #used=-1 during cancellation HDFS cached data

The issue was due to the use of HDFS caching with data files accessed by Impala. Support for HDFS caching in Impala was introduced in Impala 1.4.0 for CDH 5.1.0. The fix for this issue was backported to Impala 1.3.x, and is the only change in Impala 1.3.2 for CDH 5.0.4.

Bug: IMPALA-1019

Severity: High

Workaround: On CDH 5.0.x, upgrade to CDH 5.0.4 with Impala 1.3.2, where this issue is fixed. In Impala 1.3.0 or 1.3.1 on CDH 5.0.x, do not use HDFS caching for Impala data files in Impala internal or external tables. If some of these data files are cached (for example because they are used by other components that take advantage of HDFS caching), set the query option DISABLE_CACHED_READS=true. To set that option for all Impala queries across all sessions, start impalad with the -default_query_options option and include this setting in the option argument, or on a cluster managed by Cloudera Manager, fill in this option setting on the Impala Daemon options page.

Resolution: This issue is fixed in Impala 1.3.2 for CDH 5.0.4. The addition of HDFS caching support in Impala 1.4 means that this issue does not apply to any new level of Impala on CDH 5.

The impala-shell interpreter could encounter errors processing SQL statements containing non-ASCII characters.

Bug: IMPALA-489

Severity: High

When a view was accessed while inside a different database, references to tables were not resolved unless the names were fully qualified when the view was created.

Bug: IMPALA-962

Severity: High

If an ALTER TABLE specified a non-existent HDFS location for a partition, afterwards Impala would not be able to access the partition at all.

Bug: IMPALA-741

Severity: High

The CREATE TABLE LIKE clause was enhanced to be able to create a table with the same column definitions as a view. The resulting table is a text table unless the STORED AS clause is specified, because a view does not have an associated file format to inherit.

Bug: IMPALA-834

Severity: High

Operations on tables with many partitions could be slow due to the time to evaluate which partitions were affected. The partition pruning code was speeded up substantially.

Bug: IMPALA-887

Severity: High

The performance of the COMPUTE STATS statement was improved substantially. The efficiency of its internal operations was improved, and some statistics are no longer gathered because they are not currently used for planning Impala queries.

Bug: IMPALA-1003

Severity: High

After a CREATE TABLE LIKE statement using an Avro table as the source, the new table could have incorrect metadata and be inaccessible, depending on how the original Avro table was created.

Bug: IMPALA-185

Severity: High

Impala could encounter a serious error after a query was cancelled.

Bug: IMPALA-1046

Severity: High

A deadlock condition could make all impalad daemons hang, making the cluster unresponsive for Impala queries.

Bug: IMPALA-1083

Severity: High

The serious error in the title could occur, with the supplemental message:

num_used_buffers_ < 0: #used=-1 during cancellation HDFS cached data

The issue was due to the use of HDFS caching with data files accessed by Impala. Support for HDFS caching in Impala was introduced in Impala 1.4.0 for CDH 5.1.0. The fix for this issue was backported to Impala 1.3.x, and is the only change in Impala 1.3.2 for CDH 5.0.4.

Bug: IMPALA-1019

Severity: High

Workaround: On CDH 5.0.x, upgrade to CDH 5.0.4 with Impala 1.3.2, where this issue is fixed. In Impala 1.3.0 or 1.3.1 on CDH 5.0.x, do not use HDFS caching for Impala data files in Impala internal or external tables. If some of these data files are cached (for example because they are used by other components that take advantage of HDFS caching), set the query option DISABLE_CACHED_READS=true. To set that option for all Impala queries across all sessions, start impalad with the -default_query_options option and include this setting in the option argument, or on a cluster managed by Cloudera Manager, fill in this option setting on the Impala Daemon options page.

Resolution: This issue is fixed in Impala 1.3.2 for CDH 5.0.4. The addition of HDFS caching support in Impala 1.4 means that this issue does not apply to any new level of Impala on CDH 5.

Impala could encounter a severe error in a query combining a left outer join with an inline view containing a COUNT(DISTINCT) operation.

Bug: IMPALA-904

Severity: High

If the result of a GROUP BY operation is NULL, the resulting row might be omitted from the result set. This issue depends on the data values and data types in the table.

Bug: IMPALA-901

Severity: High

When a UDF is dropped through the DROP FUNCTION statement, and then the UDF is re-created with a new .so library or JAR file, the original version of the UDF is still used when the UDF is called from queries.

Bug: IMPALA-786

Severity: High

Workaround: Restart the impalad daemon on all nodes.

If a COMPUTE STATS statement encountered an error, the error message is "Query aborted" with no further detail. Common reasons why a COMPUTE STATS statement might fail include network errors causing the coordinator node to lose contact with other impalad instances, and column names that match Impala reserved words. (Currently, if a column name is an Impala reserved word, COMPUTE STATS always returns an error.)

Bug: IMPALA-762

Severity: High

After an ALTER TABLE statement that changes the LOCATION property of a partition, a subsequent INSERT statement would always use a path derived from the base data directory for the table.

Bug: IMPALA-624

Severity: High

A COUNT(*) operation could return the wrong result for text tables using nul characters (ASCII value 0) as delimiters.

Bug: IMPALA-13

Severity: High

Workaround: Impala adds support for ASCII 0 characters as delimiters through the clause FIELDS TERMINATED BY '\0'.

Impala could allocate more memory than necessary during certain operations.

Bug: IMPALA-488

Severity: High

Workaround: Before issuing a COMPUTE STATS statement for a Parquet table, reduce the number of threads used in that operation by issuing SET NUM_SCANNER_THREADS=2 in impala-shell. Then issue UNSET NUM_SCANNER_THREADS before continuing with queries.

When new subdirectories are created underneath a partitioned table by an INSERT statement, previously the new subdirectories always used the default HDFS permissions for the impala user, which might not be suitable for directories intended to be read and written by other components also.

Bug: IMPALA-827

Severity: High

Resolution: In Impala 1.3.1 and higher, you can specify the --insert_inherit_permissions configuration when starting the impalad daemon.

Impala could encounter a severe error in a query where the FROM list contains an inline view that includes a UNION. The exact type of the error varies.

Bug: IMPALA-888

Severity: High

The ability to specify a subset of columns in an INSERT statement, with order different than in the target table, was not working as intended.

Bug: IMPALA-945

Severity: High

The automatic join reordering optimization could incorrectly reorder queries with an outer join or semi join followed by an inner join, producing incorrect results.

Bug: IMPALA-860

Severity: High

Workaround: Including the STRAIGHT_JOIN keyword in the query prevented the issue from occurring.

A query with a GROUP BY clause referencing multiple columns could introduce incorrect NULL values in some columns of the result set. The incorrect NULL values could appear in rows where a different GROUP BY column actually did return NULL.

Bug: IMPALA-850

Severity: High

A query could return incorrect results if it combined an aggregate function call, a DISTINCT operator, and a HAVING clause, without a GROUP BY clause.

Bug: IMPALA-845

Severity: High

An aggregation query or a query with ORDER BY and LIMIT could be executed on a single node in some cases, rather than distributed across the cluster. This issue affected queries whose FROM clause referenced an inline view containing a UNION.

Bug: IMPALA-831

Severity: High

If a GROUP BY query referenced the same columns multiple times using different operators, result rows could contain multiple copies of the same expression.

Bug: IMPALA-817

Severity: High

Referencing the same columns in both a COUNT() and a SUM() call in the same query, or some other combinations of aggregate function calls, could incorrectly return a result of 0 from one of the aggregate functions. This issue affected references to TINYINT and SMALLINT columns, but not INT or BIGINT columns.

Bug: IMPALA-765

Severity: High

Workaround: Setting the query option DISABLE_CODEGEN=TRUE prevented the incorrect results. Switching the order of the function calls could also prevent the issue from occurring.

A UNION query could produce a wrong result, followed by a serious error for a subsequent UNION query.

Bug: IMPALA-723

Severity: High

Impala could return incorrect string results when reading uncompressed Parquet data files containing multiple row groups. This issue only affected Parquet data files produced by MapReduce jobs.

Bug: IMPALA-729

Severity: High

Using a column or table name that conflicted with Impala keywords could prevent running the COMPUTE STATS statement for the table.

Bug: IMPALA-777

Severity: High

The COMPUTE STATS statement did not use the setting of the MEM_LIMIT query option in impala-shell, potentially causing problems gathering statistics for wide Parquet tables.

Bug: IMPALA-903

Severity: High

The COMPUTE STATS statement could be slow or encounter a timeout while analyzing a table with many partitions.

Bug: IMPALA-880

Severity: High

If the columns for an Avro table were all defined in the TBLPROPERTIES or SERDEPROPERTIES clauses, the COMPUTE STATS statement would fail after completely analyzing the table, potentially causing a long delay. Although the COMPUTE STATS statement still does not work for such tables, now the problem is detected and reported immediately.

Bug: IMPALA-867

Severity: High

Workaround: Re-create the Avro table with columns defined in SQL style, using the output of SHOW CREATE TABLE. (See the JIRA page for detailed steps.)

A large number of concurrent CREATE TABLE statements can cause the catalogd process to consume excessive memory, and potentially be killed due to an out-of-memory condition.

Bug: IMPALA-818

Severity: High

Workaround: Restart the catalogd service and re-try the DDL operations that failed.

A large number of tables and partitions could result in unnecessary CPU overhead during Impala idle time and background operations.

Bug: IMPALA-821

Severity: High

Resolution: Catalog server processing was optimized in several ways.

A query against a TIMESTAMP column in an Avro table could encounter a serious issue.

Bug: IMPALA-828

Severity: High

Workaround: Set the query option DISABLE_CODEGEN=TRUE

Impala nodes could produce repeated error messages after recovering from a communication error with the statestore service.

Bug: IMPALA-809

Severity: High

A join query could produce wrong results if multiple equality comparisons between the same tables referred to the same column.

Bug: IMPALA-805

Severity: High

Certain outer join queries could return wrong results. If one of the tables involved in the join was an inline view, some tests from the WHERE clauses could be applied to the wrong phase of the query.

Severity: High

An HBase cell could contain a value larger than 32 KB, leading to a serious error when Impala queries that table. The error could occur even if the applicable row is not part of the result set.

Bug: IMPALA-715

Severity: High

Workaround: Use smaller values in the HBase table, or exclude the column containing the large value from the result set.

A query involving a DISTINCT operator combined with a FULL OUTER JOIN could encounter a serious error.

Bug: IMPALA-735

Severity: High

Workaround: Set the query option DISABLE_CODEGEN=TRUE

If a table had more than 32,767 partitions, Impala would not recognize the partitions above the 32K limit and query results could be incomplete.

Bug: IMPALA-749

Severity: High

Queries against HBase tables could fail with an error if the row key was compared to a function return value rather than a string constant. Also, queries against HBase tables could fail if the WHERE clause contained combinations of comparisons that could not possibly match any row key.

Severity: High

Resolution: Queries now return appropriate results when function calls are used in the row key comparison. For queries involving non-existent row keys, such as WHERE row_key IS NULL or where the lower bound is greater than the upper bound, the query succeeds and returns an empty result set.

The parquet-mr library included with CDH4.5 writes files that are not readable by Impala, due to the presence of multiple row groups. Queries involving these data files might result in a crash or a failure with an error such as "Column chunk should not contain two dictionary pages".

This issue does not occur for Parquet files produced by Impala INSERT statements, because Impala only produces files with a single row group.

Bug: IMPALA-720

Severity: High

Impala does not currently optimize the join order of queries; instead, it joins tables in the order in which they are listed in the FROM clause. Queries that contain one or more large tables on the right hand side of joins (either an explicit join expressed as a JOIN statement or a join implicit in the list of table references in the FROM clause) may run slowly or crash Impala due to out-of-memory errors. For example:

SELECT ... FROM small_table JOIN large_table

Severity: Medium

Anticipated Resolution: Fixed in Impala 1.2.2.

Workaround: In Impala 1.2.2 and higher, use the COMPUTE STATS statement to gather statistics for each table involved in the join query, after data is loaded. Prior to Impala 1.2.2, modify the query, if possible, to join the largest table first. For example:

SELECT ... FROM small_table JOIN large_table

should be modified to:

SELECT ... FROM large_table JOIN small_table

Some Parquet files could be generated by other components that Impala could not read.

Bug: IMPALA-694

Severity: High

Resolution: The underlying issue is being addressed by a fix in the CDH Parquet libraries. Impala 1.2.2 works around the problem and reads the existing data files.

The statestore service cound experience an internal error leading to a hang.

Bug: IMPALA-699

Severity: High

A UNION query where one side involved a GROUP BY operation could cause a serious error.

Bug: IMPALA-687

Severity: High

A serious error could occur when doing an INSERT into a Parquet table.

Bug: IMPALA-689

Severity: High

If the JAR file for a Java-based Hive UDF was not in the CLASSPATH, the UDF could not be called during a query.

Bug: IMPALA-695

Severity: High

While querying a table with long column values, Impala could over-allocate memory leading to an out-of-memory error. This problem was observed most frequently with tables using uncompressed RCFile or text data files.

Bug: IMPALA-525

Severity: High

Resolution: Fixed in 1.2.1

A join query could allocate a temporary work area that was larger than needed, leading to an out-of-memory error. The fix makes Impala return unused memory to the system when the memory limit is reached, avoiding unnecessary memory errors.

Bug: IMPALA-657

Severity: High

Resolution: Fixed in 1.2.1

Impala could encounter an out-of-memory condition setting up work areas for Parquet tables with many columns. The fix reduces the size of the allocated memory when not actually needed to hold table data.

Bug: IMPALA-652

Severity: High

Resolution: Fixed in 1.2.1

Certain queries involving DOUBLE columns could fail with a serious error. The fix improves the generation of native machine instructions for certain chipsets.

Bug: IMPALA-477

Severity: High

Queries could fail with a "block size is too big" error, due to NULL values in RCFile tables using Snappy compression.

Bug: IMPALA-482

Severity: High

Queries could fail if an Impala RCFile table was defined with more columns than in the corresponding RCFile data files.

Bug: IMPALA-510

Severity: High

Certain combinations of clauses in a view definition for a partitioned table could result in inefficient performance and incorrect results.

Bug: IMPALA-495

Severity: High

The SerDes class string written into Parquet data files created by Impala was updated for compatibility with Parquet support in Hive. See Incompatible Changes Introduced in Cloudera Impala 1.1.1 for the steps to update older Parquet data files for Hive compatibility.

Bug: IMPALA-485

Severity: High

A query returning a small result sets from a large table could tie up memory unnecessarily for the duration of the query.

Bug: IMPALA-534

Severity: High

Queries against Avro tables could fail depending on whether the Avro schema URL was specified in the TBLPROPERTIES or SERDEPROPERTIES field. The fix causes Impala to check both fields for the schema URL.

Bug: IMPALA-538

Severity: High

Queries could allocate substantially more memory than specified in the impalad -mem_limit startup option. The fix causes more frequent checking of the limit during query execution.

Bug: IMPALA-520

Severity: High

This issue is due to a performance tradeoff between systems running many queries concurrently, and systems running a single query. Systems running only a single query could experience lower performance than in early beta releases. Systems running many queries simultaneously should experience higher performance than in the beta releases.

Severity: High

A query could fail if it involved 3 or more tables and the last join table was specified as a subquery.

Bug: IMPALA-85

Severity: High

INSERT statements against partitioned tables using the Parquet format could use excessive amounts of memory as the number of partitions grew large.

Bug: IMPALA-257

Severity: High

The impala-shell interpreter did not accept comment entered at the command line, making it problematic to copy and paste from scripts or other code examples.

Bug: IMPALA-192

Severity: Low

The Impala web UI would sometimes display a query as if it were still running, after the query was cancelled.

Bug: IMPALA-364

Severity: High

The impala-shell command in Impala 1.0.1 does not work with Python 2.4, which is the default on Red Hat 5.

For the impala-shell command in Impala 1.0, the -o option (pipe output to a file) does not work with Python 2.4.

Bug: IMPALA-396

Severity: High

Impala might issue an erroneous error message when processing a Parquet data file produced by a non-Impala Hadoop component.

Bug: IMPALA-333

Severity: High

Resolution: Fixed

If an RCFile table definition had fewer columns than the fields actually in the data files, queries would fail.

Bug: IMPALA-293

Severity: High

Resolution: Fixed

The _HOST placeholder in the --principal startup option was not substituted with the correct hostname, potentially leading to a startup error in setups using Kerberos authentication.

Bug: IMPALA-351

Severity: High

Resolution: Fixed

A query for an HBase table could omit data from the last region.

Bug: IMPALA-356

Severity: High

Resolution: Fixed

After a region in an HBase table was split or moved, an Impala query might return incomplete or out-of-date results.

Bug: IMPALA-300

Severity: High

Resolution: Fixed

After a successful CREATE TABLE statement, the corresponding query state would be incorrectly reported as EXCEPTION.

Bug: IMPALA-349

Severity: High

Resolution: Fixed

Operations involving calls to the Java JNI subsystem (for example, queries on HBase tables) could allocate memory but not release it.

Bug: IMPALA-358

Severity: High

Resolution: Fixed

Impala returns 0 for bad time values in UNIX_TIMESTAMP, Hive returns NULL.

Impala:

impala> select UNIX_TIMESTAMP('10:02:01') ;
impala> 0

Hive:

hive> select UNIX_TIMESTAMP('10:02:01') FROM tmp;
hive> NULL

Bug: IMPALA-16

Severity: Low

Anticipated Resolution: Fixed

Insert INTO TABLE SELECT <constant> will not insert any data and may return an error.

Severity: Low

Anticipated Resolution: Fixed

A query containing both UNION and LIMIT clauses could intermittently cause the impalad process to halt with a segmentation fault.

Bug: IMPALA-183

Severity: High

Resolution: Fixed

An INSERT statement specifying a NULL value for one of the partitioning columns could cause the impalad process to halt with a segmentation fault.

Bug: IMPALA-190

Severity: High

Resolution: Fixed

In the Impala web user interface, the profile page for an INSERT statement showed obsolete information for the statement once it was complete.

Bug: IMPALA-217

Severity: High

Resolution: Fixed

Queries involving an HBase table could be slower than expected, due to excessive memory usage on the Impala nodes.

Bug: IMPALA-231

Severity: High

Resolution: Fixed

No validation was done to check that the impala-lzo shared library was compatible with the version of Impala, possibly leading to a crash when using LZO-compressed text files.

Bug: IMPALA-234

Severity: High

Resolution: Fixed

Workaround: Always upgrade the impala-lzo library at the same time as you upgrade Impala itself.

INSERT statements for tables partitioned on columns involving datetime types could appear to succeed, but cause errors for subsequent queries on those tables. The problem was especially serious if an improperly formatted timestamp value was specified for the partition key.

Bug: IMPALA-238

Severity: Critical

Resolution: Fixed

Pressing Ctrl-C in the impala-shell interpreter could sometimes display an error and return control to the shell, making it impossible to cancel the query.

Bug: IMPALA-243

Severity: Critical

Resolution: Fixed

Specifying an empty string or NULL for a partition key in an INSERT statement would fail.

Bug: IMPALA-252

Severity: High

Resolution: Fixed. The behavior for empty partition keys was made more compatible with the corresponding Hive behavior.

The round() function did not always return the correct number of significant digits.

Bug: IMPALA-266

Severity: High

Resolution: Fixed

Casting from a string literal back to the same type would cause an "invalid type cast" error rather than leaving the original value unchanged.

Bug: IMPALA-267

Severity: High

Resolution: Fixed

Some queries that returned very few rows experienced unnecessary memory usage.

Bug: IMPALA-288

Severity: High

Resolution: Fixed

A serious error could occur for relatively small and inexpensive queries.

Bug: IMPALA-289

Severity: High

Resolution: Fixed

Certain aggregation queries against Parquet tables were inefficient due to lower than required thread utilization.

Bug: IMPALA-292

Severity: High

Resolution: Fixed

The Impala CREATE TABLE command did not fill in the owner and tbl_type columns in the Hive metastore database.

Bug: IMPALA-295

Severity: High

Resolution: Fixed. The metadata was made more Hive-compatible.

The impalad instances in a cluster could halt when the statestored process became unavailable.

Bug: IMPALA-312

Severity: High

Resolution: Fixed

A subquery would fail if the SELECT statement inside it returned a constant value rather than querying a table.

Bug: IMPALA-67

Severity: High

Resolution: Fixed

The result set from a right outer join query could include erroneous rows containing NULL values.

Bug: IMPALA-90

Severity: High

Resolution: Fixed

The Parquet scanner non-deterministically hangs when executing some queries.

Bug: IMPALA-204

Severity: Medium

Resolution: Fixed

When attempting to load metadata from an unsupported Hive table type (INDEX and VIEW tables), Impala fails with an unclear error message.

Bug: IMPALA-167

Severity: Low

Resolution: Fixed in 0.7

Severity: Medium

Resolution: Fixed in 0.7

Severity: Medium

Resolution: Fixed in 0.7

Workaround: None

It is currently not possible to limit the memory consumption of a single query. All tables on the right hand side of JOIN statements need to be able to fit in memory. If they do not, Impala may crash due to out of memory errors.

Severity: High

Resolution: Fixed in 0.7

Aggregate of a subquery result set returns wrong results if the subquery contains a 'limit' clause and data is distributed across multiple nodes. From the query plan, it looks like we are just summing the results from each slave.

Bug: IMPALA-20

Severity: Low

Resolution: Fixed in 0.7

We currently can't utilize a predicate like "country_code in ('DE', 'FR', 'US')" to do partitioning pruning, because that requires an equality predicate or a binary comparison.

We should create a superclass of planner.ValueRange, ValueSet, that can be constructed with an arbitrary predicate, and whose isInRange(analyzer, valueExpr) constructs a literal predicate by substitution of the valueExpr into the predicate.

Bug: IMPALA-144

Severity: Medium

Resolution: Fixed in 0.7

Impala reads the NameNode address and port as command line parameters rather than reading them from core-site.xml. Updating the NameNode address in the core-site.xml file does not propagate to Impala.

Severity: Low

Resolution: Fixed in 0.6 - Impala reads the namenode location and port from the Hadoop configuration files, though setting -nn and -nn_port overrides this. Users are advised not to set -nn or -nn_port.

Queries may fail on secure environment due to impalad Kerberos tickets expiring. This can happen if the Impala -kerberos_reinit_interval flag is set to a value ten minutes or less. This may lead to an impalad requesting a ticket with a lifetime that is less than the time to the next ticket renewal.

Bug: IMPALA-64

Severity: Medium

Resolution: Fixed in 0.6

Concurrent queries may fail when Impala is using Thrift to communicate with part of the Hive Metastore such as the Hive Metastore Service. In such a case, the error get_fields failed: out of sequence response" may occur because Impala shared a single Hive Metastore Client connection across threads. With Impala 0.6, a separate connection is used for each metadata request.

Bug: IMPALA-48

Severity: Low

Resolution: Fixed in 0.6

Impala fails to start if it is unable to establish a connection with the Hive Metastore. This behavior was fixed, allowing Impala to start, even when no Metastore is available.

Bug: IMPALA-58

Severity: Low

Resolution: Fixed in 0.6

In some queries (including "USE database" statements), database names are treated as case-sensitive. This may lead queries to fail with an IllegalStateException.

Bug: IMPALA-44

Severity: Medium

Resolution: Fixed in 0.6

Impala does not ignore hidden HDFS files, meaning those files prefixed with a period '.' or underscore '_'. This diverges from Hive/MapReduce, which skips these files.

Bug: IMPALA-18

Severity: Low

Resolution: Fixed in 0.6

Impala may have reduced performance on tables that contain a large number of partitions. This is due to extra overhead reading/parsing the partition metadata.

Severity: High

Resolution: Fixed in 0.5

Backend impalads do not cache connections to the coordinator. On a secure cluster, this introduces a latency proportional to the number of backend clients involved in query execution, as the cost of establishing a secure connection is much higher than in the non-secure case.

Bug: IMPALA-38

Severity: Medium

Resolution: Fixed in 0.5

Concurrent queries may fail with error: "Table object has not been been initialised : `PARTITIONS`". This was due to a lack of locking in the Impala table/database metadata cache.

Bug: IMPALA-30

Severity: Medium

Resolution: Fixed in 0.5

The Impala UNIX_TIMESTAMP(val, format) operation compares the length of format and val and returns NULL if they do not match. Hive instead effectively truncates val to the length of the format parameter.

Bug: IMPALA-15

Severity: Medium

Resolution: Fixed in 0.5

Impala is impacted by Hive bug HIVE-3596 which may cause metastore refreshes to fail if a Hive temporary configuration file is deleted (normally located at /tmp/hive-<user>-<tmp_number>.xml). Additionally, the impala-shell will incorrectly report that the failed metadata refresh completed successfully.

Severity: Medium

Anticipated Resolution: To be fixed in a future release

Workaround: Restart the impalad service. Use the impalad log to check for metadata refresh errors.

The lpad/rpad builtin functions generate the wrong results.

Severity: Mild

Resolution: Fixed in 0.4

Compressed files with extensions incorrectly generate an exception.

Bug: IMPALA-14

Severity: High

Resolution: Fixed in 0.4

Some queries with large limits were hanging.

Severity: High

Resolution: Fixed in 0.4

Severity: Low

Resolution: Fixed in 0.4

If Impala is unable to load the metadata for a table for any reason, a subsequent query referring to that table will return an unknown table error message, even if the table is known.

Severity: Mild

Resolution: Fixed in 0.3

After failing to load metadata for a table, Impala removes that table from the list of known tables returned in SHOW TABLES. Subsequent attempts to query the table returns 'unknown table', even if the metadata for that table is fixed.

Severity: Mild

Resolution: Fixed in 0.3

Attempting to select from these tables fails.

Severity: Medium

Resolution: Fixed in 0.3

Queries that contain OUTER JOINs may not return the correct results if there are predicates referencing any of the joined tables in the WHERE clause.

Severity: Medium

Resolution: Fixed in 0.3.

Subqueries that contain an aggregate cannot be joined with another table or Impala may crash. For example:

SELECT * FROM (SELECT sum(col1) FROM some_table GROUP BY col1) t1 JOIN other_table ON (...);

Severity: Medium

Resolution: Fixed in 0.2

For example:

INSERT OVERWRITE TABLE test SELECT * FROM test2 LIMIT 1;

Severity: Medium

Resolution: Fixed in 0.2

For example:

SELECT * FROM test2 LIMIT 1;

Severity: Medium

Resolution: Fixed in 0.2

Attempting to read such files does not generate a diagnostic.

Severity: Medium

Resolution: Fixed in 0.2

When querying an HBase table whose row-key is string type, the Impala server may raise a null pointer exception.

Severity: Medium

Resolution: Fixed in 0.2