Avoid reading unusually large parquet footers

[raunaqmorarka]

Description

Reading unusually large parquet footers can lead to workers
going into full GC and crashing when decoding the footer in
org.apache.parquet.format.Util#readFileMetaData
This is usually caused by misconfigured parquet writers producing
too many row groups per file. This change adds a guard rail to
fail reads of such files gracefully.

Additional context and related issues

Release notes

( ) This is not user-visible or is docs only, and no release notes are required.
( ) Release notes are required. Please propose a release note for me.
(x) Release notes are required, with the following suggested text:

## Hive, Delta Lake, Iceberg, Hudi
* Prevent workers from going into full GC or crashing when decoding unusually large parquet footers. ({issue}`25973`)

[Copilot]

Pull Request Overview

Adds a safeguard against excessively large Parquet footers by introducing a configurable max-footer-read-size limit.

• Introduce maxFooterReadSize in ParquetReaderOptions and expose it via ParquetReaderConfig.
• Implement a guard in MetadataReader to throw a ParquetCorruptionException when the footer exceeds the configured size.
• Propagate the new option to all Parquet reader entry points (Iceberg, Hudi, Hive, Delta Lake) and update tests and documentation accordingly.

Reviewed Changes

Copilot reviewed 22 out of 22 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
plugin/trino-hive/src/main/java/io/trino/plugin/hive/parquet/ParquetReaderConfig.java	Add setter/getter for parquet.max-footer-read-size and remove legacy mapping
lib/trino-parquet/src/main/java/io/trino/parquet/reader/MetadataReader.java	Add overloads and guard in readFooter to enforce the footer size limit
lib/trino-parquet/src/main/java/io/trino/parquet/ParquetReaderOptions.java	Extend options and builder with maxFooterReadSize, defaulting to 15 MB
plugin/**/IcebergPageSourceProvider.java, HudiPageSourceProvider.java, DeltaLakePageSourceProvider.java, ParquetPageSourceFactory.java	Pass options.getMaxFooterReadSize() into MetadataReader.readFooter
docs/src/main/sphinx/object-storage/file-formats.md	Document the new parquet.max-footer-read-size session property

Comments suppressed due to low confidence (3)

lib/trino-parquet/src/main/java/io/trino/parquet/reader/MetadataReader.java:96

• There’s no test covering the new exception path when a footer exceeds the configured limit. Consider adding a unit test that simulates a large footer and asserts that ParquetCorruptionException is thrown.

if (maxFooterReadSize.isPresent() && completeFooterSize > maxFooterReadSize.get().toBytes()) {

lib/trino-parquet/src/main/java/io/trino/parquet/ParquetReaderOptions.java:157

• [nitpick] The builder field maxFooterSize is inconsistent with the rest of the API which uses maxFooterReadSize. Rename it to maxFooterReadSize for clarity and consistency.

private DataSize maxFooterSize;

docs/src/main/sphinx/object-storage/file-formats.md:104

• [nitpick] The list item formatting in the Sphinx document is incorrect. Change * - to - (or align with the surrounding list style) so the new property renders properly.

* - `parquet.max-footer-read-size`

[Praveen2112]

LGTM - Two minor questions

[Praveen2112]

Do we need something for ORC footer as well ?

[raunaqmorarka]

I haven't seen this situation in ORC yet, even in parquet you need really bad configuration to reach this situation