Skip to content

Add Trino 478 release note #26726

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from
Closed

Add Trino 478 release note #26726

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
56b8440
Add Trino 478 release note
ebyhr Sep 28, 2025
412d267
fixup! Add Trino 478 release note
ebyhr Oct 22, 2025
da31f20
Update docs/src/main/sphinx/release/release-478.md
ebyhr Oct 23, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions docs/src/main/sphinx/release.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,7 @@
```{toctree}
:maxdepth: 1

release/release-478
release/release-477
release/release-476
release/release-475
Expand Down
79 changes: 79 additions & 0 deletions docs/src/main/sphinx/release/release-478.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,79 @@
# Release 478 (22 Oct 2025)

## General

* Add support for column lineage in `UNNEST` clauses. ({issue}`16946`)
* Add `retry-policy.allowed` configuration property to specify which retry
policies can be selected by the user. ({issue}`26628`)
Comment on lines +6 to +7
Copy link
Member

@findepi findepi Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Add `retry-policy.allowed` configuration property to specify which retry
policies can be selected by the user. ({issue}`26628`)
* Add `retry-policy.allowed` configuration property to specify which query retry
policies can be selected by the user. ({issue}`26628`)

* Add support for loading plugins from multiple directories. ({issue}`26855`)
* Add the `/v1/integrations/gateway` endpoint for integration with Trino Gateway. ({issue}`26548`)
Copy link
Member

@findepi findepi Oct 24, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Add the `/v1/integrations/gateway` endpoint for integration with Trino Gateway. ({issue}`26548`)
* Add the `/v1/integrations/gateway` endpoint that exposes additional cluster metrics for Trino Gateway. ({issue}`26548`)

Copy link
Member

@findepi findepi Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW I am not convinced we should have added that.
Trino and Trino Gateway are both projects we manage, so we can have coupling between them. That does not mean we should or want such coupling. Everything is a trade off, of course. If this endpoint exposes information previously unavailable, and also interesting to Trino Gateway only, we perhaps want to have it. But it doesn't look like this is the case here. The endpoint exposes cluster utilization metrics (memory, load), which are generally useful for observability and also for any other query routing logic. We should expose them in gateway-agnostic manner, rather than build a public-but-do-not-use-kind-of-internal-yet-public API.

cc @andythsu @wendigo @martint

Copy link
Contributor

@wendigo wendigo Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've discussed that already and settled on the decision that it's ok to have a client specific endpoint (like we have for the UI). We can revisit this decision but if it blocks the release we should just revert the change and move on

Copy link
Member

@findepi findepi Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok to have a client specific endpoint (like we have for the UI)

UI is not the best example, because it's maintained within this repo. The UI endpoints can change as the UI needs evolve.

This new endpoint is different. It's meant for the Trino Gateway, so in theory it should not be used by any other software. Any other query routing software will needs its own endpoint, which is quite undesirable. All this while the information exposed is no way trino gateway specific and could be exposed in a more reusable manner.

We can revisit this decision but if it blocks the release we should just revert the change and move on

Agreed!

Copy link
Member

@findepi findepi Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-> https://github.com/trinodb/trino/pull/27089/files#r2459921217

Copy link
Member

@andythsu andythsu Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with you that it's undesirable to have an endpoint for each service and it should be in a reusable manner

IMO, the coupling between Trino Gateway and Trino is inevitable. If Trino changes, Trino Gateway will need to change. For example, in this PR because Trino 477 removed some of the jmx stats, which caused Trino Gateway to fail, we had to pin Trino version to 476 and look for workarounds.

For this endpoint specifically, yes the data it returns can be useful for other software as well and should be gateway-agnostic. But I think the point is that each software should deserve its own dedicated endpoint so that they are not affected by unintentional changes. Other software owners are welcome, of course, to use this endpoint, but it is their responsibility to make sure their software doesn't break at all times, even after we roll out new changes to this endpoint. It's another way of saying there's no SLA on this endpoint if they use it, whereas if we create a generic endpoint, there's implied SLA

At the end of the day, if other query routing logic software needs similar data to be returned, they will likely end up with similar code in their endpoint. Yes this results in duplicate code. But we can look into how to extract common logic to a helper function. At that point, maybe we will find some discrepancies in these seemingly-similar looking endpoints.

Copy link
Member

@findepi findepi Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I think the point is that each software should deserve its own dedicated endpoint so that they are not affected by unintentional changes.

I appreciate the openness but I doubt that would be want we would actually want to maintain in the project.

BTW trino already exports tons of metrics in standard format (that's why jmx became obsolete), so i don't quite yet understand why we need dedicated endpoints just for selected metrics useful for selected use case

* Allow dropping an uninitialized catalog that failed to load. ({issue}`26918`)
Copy link
Member

@findepi findepi Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we want to quantify this with "When using dynamic catalogs" or similar?

* When using dynamic catalogs, allow dropping ...

* Improve performance of queries with an `ORDER BY` clause. ({issue}`26725`)
Copy link
Member

@findepi findepi Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Improve performance of queries with an `ORDER BY` clause. ({issue}`26725`)
* Improve performance of queries with an `ORDER BY` clause using `varchar` or `varbinary` types. ({issue}`26725`)

* Improve performance of `MERGE` statements involving a `NOT MATCHED` case. ({issue}`26759`)
* Improve performance of queries with joins which spill to disk. ({issue}`26076`)
* Fix potential incorrect results when reading `row` type. ({issue}`26806`)
* Return all catalogs, including uninitialized ones, for queries from `metadata.catalogs`. ({issue}`26918`)
* Ensure that queries with and without `EXPLAIN ANALYZE` are planned identically.
way. ({issue}`26938`)
* In row pattern matching, restrict logical navigations to current match in running semantics. ({issue}`26981`)
Copy link
Member

@findepi findepi Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is also a bug fix, maybe

Suggested change
* In row pattern matching, restrict logical navigations to current match in running semantics. ({issue}`26981`)
* Fix row pattern matching logical navigations in running semantics to be always constraint to current match. Previously, a logical navigation function such as `FIRST` could return position outside of the current match. ({issue}`26981`)


## Security

* Propagate `queryId` to the [Open Policy Agent](/security/opa-access-control)
authorizer. ({issue}`26851`)

## Web UI

* Add support for filtering queries by `X-Trino-Trace-Token` value in the [](/admin/preview-web-interface). ({issue}`26447`)
* Improve rendering performance of large query JSON in the [](/admin/preview-web-interface). ({issue}`26807`)
* Fix rendering of large query plans in the [](/admin/preview-web-interface). ({issue}`26749`)
* Fix rendering of the splits timeline for queued queries in the [](/admin/preview-web-interface) to prevent
blank screen ({issue}`26920`)

## Docker image

* Run Trino on JDK 25.0.0 (build 36). ({issue}`26693`)
Copy link
Contributor

@wendigo wendigo Oct 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI: This will change to 25.0.1 soon

Copy link
Member

@losipiuk losipiuk Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we treating this as user visible? Because we support attaching external plugins to Trino run from official docker image?


## Delta Lake connector

* Fix failure when reading `map` type with value type is `json` and value is `NULL`. ({issue}`26700`)
Copy link
Member

@findepi findepi Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Fix failure when reading `map` type with value type is `json` and value is `NULL`. ({issue}`26700`)
* Fix failure when reading `map` type with `json` value type when a value is `NULL`. ({issue}`26700`)

* Deprecate the `gcs.use-access-token` configuration property. Use `gcs.auth-type` instead. ({issue}`26681`)

## Google Sheets connector

* Fix potential query failure when the `gsheets.delegated-user-email` configuration property
is used. ({issue}`26501`)

## Hive connector

* Add support for reading encrypted Parquet files. ({issue}`24517`, {issue}`9383`)
* Deprecate the `gcs.use-access-token` configuration property. Use `gcs.auth-type` instead. ({issue}`26681`)
* Improve performance of queries using complex predicates on `$path` column. ({issue}`27000`)
* Prevent writing invalid dates and timestamps before `1582-10-15` by the ORC writer. ({issue}`26507`)
Copy link
Member

@findepi findepi Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a bug fix

Suggested change
* Prevent writing invalid dates and timestamps before `1582-10-15` by the ORC writer. ({issue}`26507`)
* Fix writing invalid dates and timestamps before `1582-10-15` when writing ORC files by setting calendar type in the file footer. Previously, Trino did not set the calendar type in the file footer, and values before `1582-10-15` could be read incorrectly by other query engines such as Apache Hive. ({issue}`26507`)

Copy link
Member

@findepi findepi Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marcinsbd @raunaqmorarka does this apply to Iceberg connector too?


## Hudi connector

* Deprecate the `gcs.use-access-token` configuration property. Use `gcs.auth-type` instead. ({issue}`26681`)

## Iceberg connector

* Improve performance when writing sorted tables and `iceberg.sorted-writing.local-staging-path`
is set. ({issue}`24376`)
* Return execution metrics while running the `remove_orphan_files` procedure. ({issue}`26661`)
Copy link
Member

@findepi findepi Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's not "procedure". The code calls this "table procedure"
But the docs calls it "command" https://trino.io/docs/current/connector/iceberg.html#remove-orphan-files

Suggested change
* Return execution metrics while running the `remove_orphan_files` procedure. ({issue}`26661`)
* Return execution metrics while running the `remove_orphan_files` command. ({issue}`26661`)

* Deprecate the `gcs.use-access-token` configuration property. Use `gcs.auth-type` instead. ({issue}`26681`)
* Collect distinct values count on all columns when replacing tables. ({issue}`26983`)
* Fix failure due to column count mismatch when executing the `add_files_from_table`
procedure. ({issue}`26774`)
* Fix failure when executing `optimize_manifests` on tables without a snapshot. ({issue}`26970`)
* Fix incorrect results when reading Avro files migrated from Hive. ({issue}`26863`)
* Fix failure when executing `SHOW CREATE SCHEMA` on a schema with unsupported properties
with REST, Glue or Nessie catalog. ({issue}`24744`)

## Kafka connector

* Fix failure when filtering partitions by timestamp offset. ({issue}`26787`)

## SPI

* Require `shutdown` to be implemented by the `Connector`. ({issue}`26718`)
Copy link
Member

@findepi findepi Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Connector is the name of the interface connectors implement.
The interface does not implement shutdown. Quite contrary, it lost its default implementation.

Suggested change
* Require `shutdown` to be implemented by the `Connector`. ({issue}`26718`)
* Remove default implementation from `Connector.shutdown()`. ({issue}`26718`)

* Deprecate `io.trino.spi.type.Type#appendTo` method. ({issue}`26922`)