Fixed Issues in Impala

Fixed issues for Impala are addressed in Cloudera Runtime 7.3.2, its service packs and cumulative hotfixes.

Cloudera Runtime 7.3.2.10000 SP1

CDPD-105759: Incorrect results from a LEFT JOIN converted to an INNER JOIN
7.3.2.10000
Previously, when the enable_outer_join_to_inner_transformation option was enabled, a LEFT JOIN query whose WHERE clause used a NOT(... AND ...) predicate was incorrectly converted to an INNER JOIN, which dropped rows that contained NULL values and returned incorrect results.
This issue is resolved by correctly identifying nullable predicates so that the join is not converted when the conversion would change the result.

Apache Jira: IMPALA-14685

CDPD-97102: Incorrect matching for a LIKE pattern with a leading wildcard and an escaped trailing percent sign
7.3.2.10000
Previously, a LIKE pattern that combined a leading wildcard with an escaped trailing percent sign, such as LIKE '%abc\%', matched any string containing abc\ instead of strings ending in a literal abc%, returning incorrect results.
This issue is resolved by correctly handling the escaped percent sign in the pattern.

Apache Jira: IMPALA-14731

CDPD-98998: Query hangs when the select list contains an unaliased expression with Unicode letters
7.3.2.10000
Previously, a query hung indefinitely, and could not be cancelled, when its select list contained a complex expression with Unicode letters and no column alias.
This issue is resolved by correcting the parsing loop so that the query proceeds to planning instead of hanging.

Apache Jira: IMPALA-14551

CDPD-98992: Impala crashes when aes_decrypt receives invalid input
7.3.2.10000
Previously, the aes_decrypt function crashed the impalad process when it received an input string shorter than 16 bytes in AES_128_GCM mode.
This issue is resolved by validating undersized input so that the function returns without crashing.

Apache Jira: IMPALA-14666

CDPD-102537: Catalogd deadlock during startup
A deadlock condition previously occurred in Catalogd during startup when the initial global metadata reset operation took place under a heavy workload. The thread performing the initial global reset periodically released the write lock to allow metadata operations on loaded databases to proceed. If a database was not yet loaded, a concurrent thread acquired a read lock and waited for the database to load. However, the initial global reset thread could not proceed because it required that same write lock, resulting in a deadlock.
This issue is now resolved by reversing the order of operations. The getOrLoadTable functionality now waits for the initial database metadata to load for the specified database before it acquires the versionLock_ read lock.

Apache Jira: IMPALA-14949

CDPD-99049: Spurious table-not-found errors when workload management is first enabled
7.3.2.10000
Previously, when workload management was enabled for the first time, the catalog service logged misleading errors that the sys.impala_query_log and sys.impala_query_live tables were not found, even though the tables were created automatically and the feature worked correctly.
This issue is resolved by checking whether the tables exist instead of resetting metadata, which removes the spurious errors.

Apache Jira: IMPALA-14468

CDPD-99017: Partition pruning fails when an IN list compares columns of mismatched types
7.3.2.10000
Previously, partition pruning failed with an IllegalStateException when a query used an IN list that compared a partition column with values of a different type, such as a string against a date.
This issue is resolved by validating the types before comparison so that pruning handles mismatched types correctly.

Apache Jira: IMPALA-14569

CDPD-98946: Impala crashes when viewing the web UI details of a failed query
7.3.2.10000
Previously, opening the query details page in the web UI for a query that had failed and didn't generate summary.
This issue is resolved by checking for the summary data before reading it.

Apache Jira: IMPALA-14791

CDPD-98954: Admission control service crashes when processing compressed requests
7.3.2.10000
Previously, the global admission control service (admissiond) crashed while dequeuing compressed admission requests, because a cached buffer was freed while queued entries still referenced it.
This issue is resolved by keeping the buffer valid until all dependent entries finish using it.

Apache Jira: IMPALA-14771

CDPD-100324: CREATE TABLE AS SELECT fails an internal validation check
7.3.2.10000
Previously, a CREATE TABLE AS SELECT statement could fail an internal validation check when selecting from an external table with certain properties across databases.
This issue is resolved by introducing a mechanism that asynchronously cleans up cancelled query entries from the state map.

Apache Jira: IMPALA-14875

CDPD-101262: A pool can exceed its maximum memory when query memory limits are not set
7.3.2.10000
Previously, queries in a resource pool could use more memory than the configured pool Max Memory when the pool had no minimum or maximum query memory limit and no MEM_LIMIT query option was set, because Impala allowed unlimited memory instead of applying the pool maximum.
This issue is resolved by enforcing the pool maximum memory even when the query memory limits are not configured.

Apache Jira: IMPALA-14840

CDPD-97080: Memory leak in the admission control service when queued queries are cancelled
7.3.2.10000
Previously, the global admission control service leaked memory when queries waiting in the admission queue were cancelled, because their entries were not removed from the internal state map.
This issue is resolved by introducing a mechanism that asynchronously cleans up cancelled query entries from the state map.

Apache Jira: IMPALA-14605

CDPD-56422: Queries fail when a column comment exceeds 256 characters
7.3.2.10000
Previously, a query failed when a table column had a comment longer than 256 characters, even though the Hive Metastore stored the longer comment.
This issue is resolved by handling oversized comments so that the query runs normally.

Apache Jira: IMPALA-3451

CDPD-107170: AI endpoint validation could allow URLs that were not from an allowed provider
7.3.2.10000
Previously, Cloudera AI checked allowed AI endpoints by looking for the allowed domain anywhere in the URL. As a result, a URL that contained an allowed domain only in its path or query parameters could pass validation, even when its actual hostname was not from an allowed provider.
This issue is resolved by updating URL validation for AI endpoints in Impala. While Impala already restricted requests to an allow list of providers, the validation now uses a stricter exact hostname parsing rather than a simple substring match. This change reduces edge cases where allowed domain strings hidden in URL paths or parameters might bypass the policy.
CDPD-106242: Server-side request forgery and unauthorized schema access through Avro schema URL
7.3.2.10000
Previously, specifying a URL in the avro.schema.url table property made unrestricted HTTP requests and exposed raw file or HTTP response details in error messages.
This issue is resolved by disabling remote HTTP requests by default for the avro.schema.url table property in Impala. If required, you can enable remote HTTP requests by using the avro_schema_url_remote_http_enabled and avro_schema_url_http_allowed_hosts configuration properties.
CDPD-106242: Uncontrolled remote HTTP requests in Avro schema URLs
7.3.2.10000
Previously, processing avro.schema.url properties allowed connections to arbitrary external hosts and allowed remote file reads without system controls.
This issue is resolved by adding Ranger read permission checks for local filesystem paths in Impala. Previously, requests using local filesystem schemes, such as local:// or hdfs://, in the avro.schema.url table property were unguarded and allowed unauthorized file reads without proper access controls.

Cloudera Runtime 7.3.2.100 CHF 1

There are no fixed issues in this release.

Cloudera Runtime 7.3.2

Cloudera Runtime 7.3.2 resolves Impala issues and incorporates fixes from the service packs and cumulative hotfixes from 7.3.1.100 through 7.3.1.706. For a comprehensive record of all fixes in Cloudera Runtime 7.3.1.x, see Fixed Issues.

CDPD-98207: Impala crashing on the Web UI for failed queries
7.3.2
Previously, Impala crashed when you accessed the query summary or JSON plan through the Web UI for queries that failed before execution. This occurred during scenarios such as a Create Table As Select (CTAS) failure or when admission control rejected a query.
This issue is addressed by ensuring the system correctly handles missing execution summaries. This issue is now fixed.

Apache Jira: IMPALA-14791

CDPD-97786: Excessive partition events during table-level operations
7.3.2
Previously, certain table-level operations, such as dropping incremental statistics or setting/unsetting cached properties, triggered an individual ALTER PARTITION event for every partition in a table.
This issue is addressed by implementing bulk updates for partitions.

Apache Jira: IMPALA-13599

CDPD-97187: Deprecation warnings in impala-shell with Python 3.11
7.3.2
Previously, when running impala-shell by using Python 3.11 or newer, the command output displayed DeprecationWarning messages related to ssl.PROTOCOL_TLS and ssl.match_hostname(). These warnings were triggered by underlying library dependencies.
This issue is now resolved by updating the handling of SSL protocols and validating logic to be compatible with newer Python versions, which eliminates these warning messages from the shell output.

Apache Jira: IMPALA-12219

CDPD-91994: Stale query IDs in catalog logs
7.3.2
Previously, catalog logs for getPartialCatalogObject certain metadata requests displayed incorrect query IDs.
This issue is addressed by ensuring that each request is associated with its correct query ID. The system now automatically clears the identification after the request finishes to prevent stale information from appearing in later logs.

Apache Jira: IMPALA-14494

CDPD-82673: RSASSA-PSS certificate signature schema is now supported for server certificates
7.3.2
Previously, if you used a certificate with the RSASSA-PSS signature algorithm for kRPC communication, the connection failed.
The fix includes an updated OpenSSL function that correctly identifies the hash algorithm for RSASSA-PSS certificates.

Apache Jira: IMPALA-14038

CDPD-89852: Crash when casting timestamp strings with timezone offsets to DATE
7.3.2
Attempting to cast a timestamp string that included a timezone offset (like "+08:00" in "2025-08-31 06:23:24.9392129 +08:00" ) to the DATE data type would cause a crash.
This issue is addressed by adding a check to ensure that the timestamp string length does not exceed the maximum length of the default date-time format. Longer strings will now use a lazily-created format, which prevents the crash.

Apache Jira: IMPALA-14383

CDPD-89730: Impala daemon crashed during scans with high logging levels
7.3.2
Previously, the Impala daemon experienced a null pointer dereference in the BaseSequenceScanner component when the logging level was set to 2 or higher, leading to crashes in release builds.
This issue is resolved by correcting the pointer handling in the sequence scanner to ensure safe memory access when high-level logging is active.

Apache Jira: IMPALA-14382

CDPD-89346: Enhanced join strategy selection for large clusters
7.3.2
The query planner's cost model for broadcast joins can be skewed by the number of nodes in a cluster. This lead to suboptimal join strategy choices, especially in large clusters with skewed data where a partitioned join was chosen over a more efficient broadcast join.
This issue is now resolved by introducing the broadcast_cost_scale_factor query option as an additional tuning option besides query hint to override query planner decision.

Apache Jira: IMPALA-14263

CDPD-89132: Tables incorrectly dropped by stale HMS events after global metadata invalidation
7.3.2
Previously, a stale event such as DropTable or AlterTableRename post global INVALIDATE METADATA command could cause tables to be unintentionally dropped
This issue is resolved by tracking the createEventId as the current HMS event ID for all tables during a global reset.

Apache Jira: IMPALA-14330

CDPD-79111: Authentication failure in impala-shell with 76 character LDAP passwords
7.3.2
Previously, when you used impala-shell with the HS2-HTTP protocol and a 76 character LDAP password, the connection failed with a value error.
This issue is resolved by an updated encoding method that handles long password strings without inserting line breaks, ensuring that the authorization header remains valid for the server.

Apache Jira: IMPALA-13746

CDPD-92001: Metadata loading performed sequentially in local catalog mode
7.3.2
Previously, when a query accessed multiple unloaded tables in local catalog mode, Impala triggered metadata loading for those tables sequentially.
This issue is resolved by parallelizing table loading during query compilation. A new startup flag, max_stmt_metadata_loader_threads, is introduced to control the number of threads used for loading metadata, with a default value of 8 threads per query. If only one table requires loading or if the thread pool is unavailable, the system automatically falls back to sequential loading.

IMPALA-14447

CDPD-79241: Incorrect query results for Iceberg V2 tables
7.3.2
Previously, when you ran complex queries involving multiple subqueries on Iceberg V2 tables, the system sometimes returned incorrect results.
This issue is now resolved. The fix includes a new internal mechanism to track and apply count optimizations.
Cookie-Based authentication support for JWT tokens
7.3.2
When JWT tokens are used for authentication, every HTTP request within a session requires token verification. If these tokens have a short lifespan, it can lead to authentication failures and disrupt session continuity.
This issue is now resolved by using authentication cookies, which generally have a longer lifespan (configured through the max_cookie_lifetime_s flagfile option) and can remain valid for the duration of the session. This enables subsequent authentication requests to rely on cookies rather than repeatedly verifying the JWT token.

Apache Jira: IMPALA-13813

CDPD-80798: Stable Catalogd initialization in HA mode
7.3.2
Catalogd initialization previously might timeout to complete in high availability mode. This happened because metadata operations started prematurely, blocking Catalogd from becoming active.
This issue is resolved by ensuring Catalogd determines HA state before starting metadata operations in HA mode. This prevents blocking issues and ensures a stable startup.

Apache Jira: IMPALA-13850

CDPD-83059: Optimized Impala Catalog cache warmup
7.3.2
Impala's Catalogd previously started with an empty cache. This led to slow query startup for important tables and affected high availability failovers.
This issue is resolved by adding new settings to pre-load specific tables into the Catalogd cache in the background. This ensures faster query startup and smoother high availability failovers.

Apache Jira: IMPALA-14074

CDPD-87222: Consistent TRUNCATE operations for external tables
7.3.2
Impala's TRUNCATE operations on external tables previously did not consistently delete files in subdirectories, even when recursive listing was enabled.
This issue is resolved by ensuring Impala uses the HMS API for TRUNCATE operations by default.

Apache Impala: IMPALA-14189, IMPALA-14224

DWX-21855: Impala Executors fail to gracefully shutdown
7.3.2
During graceful shutdown Impala executors wait for running queries to finish up to the graceful shutdown deadline (--shutdown_deadline_s). During graceful shutdown the istio-proxy container on Impala executor pod was getting terminated immediately and as a result the executors were not reachable and were removed from the Impala cluster membership resulting in cancellation of running queries.
This issue is now resolved by making sure istio-proxy container’s lifecycle doesn’t impact executor’s cluster membership.
IMPALA-14263: Enhanced join strategy for large clusters
7.3.2
The query planner's cost model for broadcast joins can be skewed by the number of nodes in a cluster. This could lead to suboptimal join strategy choices, especially in large clusters with skewed data where a partitioned join was chosen over a more efficient broadcast join.
This issue is now resolved by introducing the broadcast_cost_scale_factor query option as an additional tuning option besides query hint to override query planner decision. To set it cluster-wide for all queries, add the following key-value to the default_query_options startup option:
broadcast_cost_scale_factor=<less than 1.0>

Apache Jira: IMPALA-14263

IMPALA-11402: Fetching metadata for tables with huge numbers of files no longer fails with OutOfMemoryError
7.3.2
Previously, when Impala Coordinator tried to fetch file metadata for extremely large tables (those with millions of files or partitions), the Impala Catalog service would attempt to return all the file details at once. This often exceeded the Java memory limits, causing the service to crash with an OutOfMemoryError.
This issue is addressed by configuring the Catalog service to limit the number of file descriptors included in a single getPartialCatalogObject response. A new configuration flag, catalog_partial_fetch_max_files, is introduced to define the maximum number of file descriptors allowed per response (with a default of 1,000,000 files).
If a request exceeds this limit, the Catalog service will truncate the response and return metadata for only a subset of the requested partitions. The coordinator is now designed to detect this truncated response and automatically send new batch requests to fetch the remaining partitions until all required metadata is retrieved. This change ensures that the coordinator can successfully fetch and process the metadata for extremely large tables without crashing due to memory limits.

Apache Jira: IMPALA-11402

CDPD-77261: Impala can now read Parquet integer data as DECIMAL after schema changes
7.3.2
Previously, if you changed a column type from an integer (INT or BIGINT) to a DECIMAL using ALTER TABLE, Impala could fail to read the original Parquet data files. This happened because the files lacked the specific metadata (logical types) Impala expected for decimals, resulting in an error.
Impala is now more flexible when reading Parquet files following schema evolution. If Impala encounters an integer type but the schema expects a DECIMAL, it automatically assumes a suitable decimal precision and scale, allowing you to successfully query the updated table:
  • INT32 is read as DECIMAL(9, 0).
  • INT64 is read as DECIMAL(18, 0).
This change supports common schema evolution practices by allowing you to update column types without manually rewriting old data files.

Apache Jira: IMPALA-13625

IMPALA-12927: Impala can now correctly read BINARY columns in JSON tables
7.3.2
Previously, Impala couldn't correctly read BINARY columns in JSON tables, often resulting in errors or incorrect data. This happened because Impala assumed the data was always Base64 encoded, which wasn't true for files written by older Hive versions.
Impala now supports a new table property, 'json.binary.format' (BASE64 or RAWSTRING), and a query option, JSON_BINARY_FORMAT, to explicitly define the binary encoding. This ensures Impala reads the data correctly. If no format is specified, Impala will now return an error instead of risking silent data corruption.

JIRA Issue: IMPALA-12927