Known issues in Trino

Known issues identified in the May 13, 2026 release

DWX-23347: Trino restore process is not fully idempotent

In Trino Virtual Warehouses, the backup and restore process is only partly idempotent. Running the restore process more than once when Trino is not present can cause errors. While the system creates the objects, the connectors might not attach to the Virtual Warehouse correctly. This results in connectors that exist but are not properly linked.

Avoid running the restore process multiple times for the same Trino Virtual Warehouse. Make sure the restore completes successfully in one attempt to keep connectors attached.

DWX-23349: Updating Trino Virtual Warehouse worker size fails to take effect on 1.12.4 environments

On Cloudera Data Warehouse environments upgraded to 1.12.4, attempting to update the worker count for an existing Trino Virtual Warehouse through the Details > Sizing and Scaling tab fails to apply. Although the UI displays an Updating status and eventually returns to a Healthy state, the change is discarded, and the original worker count remains unchanged. This issue occurs because the Virtual Warehouse was created using an older runtime version, which is incompatible with the Istio-based ingress architecture introduced in 1.12.4. Consequently, scaling operations for these legacy Virtual Warehouses fail silently without alerting the user.

You must delete and recreate the Trino Virtual Warehouses using the latest available runtime version in the 1.12.4 environment to ensure compatibility and successful scaling.

DWX-23391: Trino Virtual Warehouse fails to attach connectors using different secret providers

On Azure-based Trino Virtual Warehouses, attaching multiple connectors, such as Teradata and MySQL, fails if the secrets are stored in different secret providers or different Azure Key Vaults. Similarly, on AWS-based Trino Virtual Warehouses, the operation fails if secrets are stored in different secret providers or different regions. During a Virtual Warehouse update, Trino validates that all secrets share a single provider; if they do not, the operation fails with an error:

Unable to mount secrets - secret <name-1> does not have the same provider as secret <name-2>

When this occurs, the update fails, connectors are not attached, and the Trino Virtual Warehouse will move to a bad health state.

Ensure all secrets for a single Trino Virtual Warehouse are stored in the same secret provider. For example, the same Azure Key Vault for Azure or the same region for AWS.

Known issues identified before the May 13, 2026 release

DWX-23214: Cloudera Data Warehouse Secret Management ARNs conflict with AWS Secrets Manager

When using AWS Secrets Manager, assigning different secret names in Cloudera Data Warehouse Secret Management to the same AWS ARN causes a conflict. As a result, the secrets overwrite each other, and only one secret remains available on the cluster.

To avoid this issue, ensure that each secret in Cloudera Data Warehouse is mapped to a unique AWS ARN. Do not map multiple Cloudera Data Warehouse secrets to the same AWS ARN.

DWX-23229: Trino Virtual Warehouse fails to start due to incompatible connector configuration

Trino Virtual Warehouse created using the latest 2025.0.21.0 version might not support certain connector configurations leading to compatibility issues, which can prevent the Trino Virtual Warehouse from starting.

If a start-up failure occurs, use one of the following options to resolve the issue:

1. After creating a new Trino Virtual Warehouse update the configuration of the affected connector, including the default Hive and Iceberg connectors. Use the Rebuild option to restore the Virtual Warehouse to good health.
2. Delete the older Trino Virtual Warehouse along with the existing federation connectors, and then create a new Trino Virtual Warehouse. The newly created Virtual Warehouse automatically applies the correct default configurations for the Hive and Iceberg connectors. For custom-created Trino connectors, it is required to manually update the configuration settings to ensure compatibility with the latest Trino versions.

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-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.