Known issues in Trino

Known issues identified in the March 31, 2026 release

DWX-22835/DWX-22745: Trino is unable to access Snowflake schemas created in lowercase

When accessing Snowflake schemas or tables through Trino (using Cloudera Data Explorer (Hue) or the Trino CLI), queries may fail with a TABLE_NOT_FOUND error, even if the table is visible in Data Explorer. This issue can occur when objects in Snowflake were created using explicit lowercase names with double quotes. In Snowflake, if you create a schema or table in lowercase without double quotes (for example, create schema my_schema), Snowflake automatically stores the name in uppercase (MY_SCHEMA). If you create it using lowercase within double quotes (for example, create schema "my_schema"), the object is stored in lowercase.

Set the Snowflake connector property, case-insensitive-name-matching to "true" to allow Trino to access these objects.

DWX-22659: cm_trino Ranger service user impersonation defaults should be more restrictive

The Ranger Trino authorization service (cm_trino) is configured with a default security posture that is too permissive. By default, the Ranger configuration parameter, ranger.default.policy.groups is populated with a specific administrative group (_c_ranger_admins_…). As a result, the default Ranger policy, "all - trinouser" allows all users within this administrative group to impersonate any other user.

Apply one of the following recommendations to ensure a more restrictive user impersonation:

• Modify the "all - trinouser" Ranger policy to include only the required technical service users (typically those prefixed with srv_) who require the ability to act on behalf of any user.
• Create a self-impersonation policy in the Ranger Trino service that grants impersonation permissions under "Allow Conditions" for the Trino user, "{USER}". This ensures each user can impersonate only themselves.

DWX-22360: ArrayIndexOutOfBoundsException when querying large MariaDB tables

When querying extremely large tables (containing hundreds of millions of rows or more) using the MariaDB connector, users may encounter an ArrayIndexOutOfBoundsException.

To avoid this issue, adopt the following data storage strategy:

• Use MariaDB only for small to medium-sized dimension tables.
• Offload large fact tables to scalable storage solutions such as HDFS, Ozone, or cloud object stores.

DWX-22578: Large queries fail with "Per-Node Memory Limit Exceeded" despite spilling enabled

Large queries involving heavy joins may fail with a "per-node memory limit exceeded" error, even if the "spill-to-disk" feature is properly enabled. This issue is primarily caused by missing or inaccurate table statistics, particularly on join columns. Without accurate statistics, the Trino query optimizer may select suboptimal join strategies that cause memory usage to spike rapidly, hitting the node limit before the spill mechanism can react.

Perform the following workarounds:

You can force the query to use a partitioned join strategy by running the following session command before your query:

SET SESSION join_distribution_type = 'PARTITIONED';

Alternatively, you can force the optimizer to avoid broadcasting large tables by lowering the size limit. For example:

SET SESSION join_max_broadcast_table_size = '10MB';

To permanently address the root cause, ensure that table and column statistics are accurate and up-to-date. This allows the optimizer to automatically select the most efficient execution plan without requiring session overrides.

DWX-22392: Trino compute update fails due to entity being leased by a background operation

Trino auto-suspend and auto-scaling processes do not account for manual operations performed by users, such as Start or Update. To prevent conflicts between manual and automatic operations, a 1-minute delay is introduced, during which the lease of the Trino Virtual Warehouse is held after a manual operation is executed. During this delay, attempting another manual operation may result in the error message: "Compute entity is currently ‘leased’ by another internal operation."

This behavior is intentional and ensures system stability. Wait for 1 minute after completing a manual operation before initiating another.

DWX-21891: Delayed metadata loading in Cloudera Data Explorer (Hue) for auto-suspended Trino Virtual Warehouses

When a Data Explorer session starts, Data Explorer sends requests to the Trino coordinator to fetch database metadata. For large metadata tables, the coordinator divides the metadata request into "splits" and assigns them to worker nodes. However, if the Trino Virtual Warehouse is auto-suspended, all worker nodes are stopped, causing the metadata request to be queued. This triggers the auto-start process to spin up the worker nodes. Since it can take a few minutes to start worker nodes in a Kubernetes cluster, Data Explorer may take a long time to load metadata for an auto-suspended Trino Virtual Warehouse.

Disable auto-suspend for the Trino Virtual Warehouse and enable auto-scaling with a minimum of one worker node to ensure at least one worker is always available.

DWX-21977: Cloudera Data Warehouse allows the deletion of a federation connector associated with a Trino Virtual Warehouse

Cloudera Data Warehouse allows you to delete a federation connector associated with a Trino Virtual Warehouse. However, the Virtual Warehouse can continue using the connector until it is restarted. This behavior occurs because the Virtual Warehouse stores connector information in the local pods. This issue, referred to as a stale connector issue, may occur if a user updates or deletes a connector already in use by the Virtual Warehouse

None.

CDPD-76644: information_schema.table_privileges metadata is unsupported

Querying the information_schema.table_privileges access control metadata for ranger is unsupported and a TrinoException is displayed indicating that the connector does not support table privileges.

None.

CDPD-76643/CDPD-76645: SET AUTHORIZATION SQL statement does not modify Ranger permissions

The following SQL statements do not dynamically modify the Ranger permissions:

CREATE SCHEMA test_createschema_authorization_user AUTHORIZATION user;
      ALTER SCHEMA test_schema_authorization_user SET AUTHORIZATION user;

As an Administrator, you can authorize the permissions from the Ranger Admin UI.

CDPD-68246: Roles related operations are not authorized by Ranger Trino plugin

The SHOW ROLES, SHOW CURRENT ROLES, and SHOW ROLE GRANT statements are not authorized by Ranger Trino plugin. Users can run these commands without any policy and audits are not generated for these statements.

None.

CDPD-81960: Row filter policy for same resource and same user across different Ranger services is not supported

When you have row filter policy for same resource and same user in both cm_trino and cm_hive (Hadoop SQL) Ranger services and the row filtering conditions are different, then on querying the table using that user returns empty response in the trino-cli.

Do not create row filter policies for the same resource and same user in different Ranger services.

DWX-19626: Number of rows returned by Trino does not match with the Hive query results

If you are running an exact same query on both Hive and Trino engine that involves dividing integers, it was observed that the query results returned by Trino does not match with the query results returned by the Hive engine. This is due to a default behavior of Trino when dividing two integers. Trino does not cast the result into a FLOAT data type.

While performing a floating point division on two integers, cast one of the integers to a DOUBLE. For more information, see the Trino documentation.