@Rocky I have an Iceberg table with PARTITION BY hour(

data_timestamp

) -

data_timestamp

datetime type, When I query MAX/MIN I get corrupted results Can you tell me if following was fixed in 4.0 and 4.1 branches?

mysql> SELECT MIN(data_timestamp), MAX(data_timestamp) FROM iceberg_prod.schema.iceberg_table_name;
+---------------------+---------------------+
| min(data_timestamp) | max(data_timestamp) |
+---------------------+---------------------+
| �9�3-11-24 00:00:00   | 0000-01-01 00:00:00 |
+---------------------+---------------------+
1 row in set (0.21 sec)

In DataGrip with SR JDBC Driver 
#,min(data_timestamp),max(data_timestamp)
  1,"<failed to load>
  java.lang.NumberFormatException: Invalid integer format for value '�9�3'
      at com.starrocks.cj.protocol.a.MysqlTextValueDecoder.getLong(MysqlTextValueDecoder.java:241)
      at com.starrocks.cj.protocol.a.MysqlTextValueDecoder.getInt(MysqlTextValueDecoder.java:170)
      at com.starrocks.cj.protocol.a.MysqlTextValueDecoder.getTimestamp(MysqlTextValueDecoder.java:376)
      at com.starrocks.cj.protocol.a.MysqlTextValueDecoder.decodeDatetime(MysqlTextValueDecoder.java:86)
      at com.starrocks.cj.protocol.result.AbstractResultsetRow.decodeAndCreateReturnValue(AbstractResultsetRow.java:78)
      at com.starrocks.cj.protocol.result.AbstractResultsetRow.getValueFromBytes(AbstractResultsetRow.java:235)
      at com.starrocks.cj.protocol.a.result.ByteArrayRow.getValue(ByteArrayRow.java:82)
      at com.starrocks.cj.jdbc.result.ResultSetImpl.getLocalDateTime(ResultSetImpl.java:988)
      at com.starrocks.cj.jdbc.result.ResultSetImpl.getObject(ResultSetImpl.java:1265)
      in JdbcHelperImpl.getObject(JdbcHelperImpl.java:406)
  ",0001-01-01 00:00:00

Correct result: after enable_min_max_optimization=false
#,min(data_timestamp),max(data_timestamp)
1,2026-04-26 01:00:00,2026-05-24 13:00:00

This issue appears to be a known bug related to the Iceberg min/max value typing during metadata-based query optimization. When a table is partitioned using transforms like

hour()

, Iceberg stores the partition values as integers (representing hours since the epoch). If StarRocks attempts to optimize a `MIN`/`MAX` query by reading these statistics from the manifest files without correctly handling the type conversion or byte decoding for the original

datetime

column, it results in corrupted strings (like

93-11-24

) or

java.lang.NumberFormatException

in the JDBC driver. Status in 4.0 and 4.1 Branches Yes, this issue has been addressed in both the 4.0 and 4.1 branches. * StarRocks 4.0: The fix was tracked under Issue #65551 ("Iceberg min/max value typing issue") and is included in the 4.0.x release line (specifically starting around v4.0.2/v4.0.3 and later). * StarRocks 4.1: This branch includes all fixes from the 4.0 line. If you are using v4.1.0 or later, the fix should be present. Recommended Actions 1. Upgrade: We recommend upgrading to the latest stable release of the 4.0.x (e.g., v4.0.10) or 4.1.x (e.g., v4.1.1) series to ensure you have the complete fix and related metadata scan improvements. 2. Workaround: Until you can upgrade, you can continue to disable the metadata-based optimization at the session level to ensure data correctness:

sql
    -- In newer versions, this is the preferred variable
    SET enable_rewrite_simple_agg_to_meta_scan = false;

    -- Or the variable you are currently using
    SET enable_min_max_optimization = false;

If you still see this behavior after upgrading to v4.0.10+ or v4.1.1+, please verify if the issue persists specifically for tables with hidden partitioning (transforms like

hour

,

day

) and consider providing a query profile to the community on Slack or GitHub for further investigation. References • sql-reference/System_variable.md • using_starrocks/async_mv/use_cases/query_rewrite_with_materialized_views.md • using_starrocks/sorted_aggregate.md • administration/management/FE_configuration.md • using_starrocks/async_mv/feature-support-asynchronous-materialized-views.md

@Rocky I have an Iceberg table with PARTITION BY hour(

data_timestamp

) -

data_timestamp

datetime type, Version 4.0.10 When I query MAX/MIN I get corrupted results Can you tell me if following was fixed in 4.0 and 4.1 branches?

mysql> SELECT MIN(data_timestamp), MAX(data_timestamp) FROM iceberg_prod.schema.iceberg_table_name;
+---------------------+---------------------+
| min(data_timestamp) | max(data_timestamp) |
+---------------------+---------------------+
| �9�3-11-24 00:00:00   | 0000-01-01 00:00:00 |
+---------------------+---------------------+
1 row in set (0.21 sec)

In DataGrip with SR JDBC Driver 
#,min(data_timestamp),max(data_timestamp)
  1,"<failed to load>
  java.lang.NumberFormatException: Invalid integer format for value '�9�3'
      at com.starrocks.cj.protocol.a.MysqlTextValueDecoder.getLong(MysqlTextValueDecoder.java:241)
      at com.starrocks.cj.protocol.a.MysqlTextValueDecoder.getInt(MysqlTextValueDecoder.java:170)
      at com.starrocks.cj.protocol.a.MysqlTextValueDecoder.getTimestamp(MysqlTextValueDecoder.java:376)
      at com.starrocks.cj.protocol.a.MysqlTextValueDecoder.decodeDatetime(MysqlTextValueDecoder.java:86)
      at com.starrocks.cj.protocol.result.AbstractResultsetRow.decodeAndCreateReturnValue(AbstractResultsetRow.java:78)
      at com.starrocks.cj.protocol.result.AbstractResultsetRow.getValueFromBytes(AbstractResultsetRow.java:235)
      at com.starrocks.cj.protocol.a.result.ByteArrayRow.getValue(ByteArrayRow.java:82)
      at com.starrocks.cj.jdbc.result.ResultSetImpl.getLocalDateTime(ResultSetImpl.java:988)
      at com.starrocks.cj.jdbc.result.ResultSetImpl.getObject(ResultSetImpl.java:1265)
      in JdbcHelperImpl.getObject(JdbcHelperImpl.java:406)
  ",0001-01-01 00:00:00

Correct result: after enable_min_max_optimization=false
#,min(data_timestamp),max(data_timestamp)
1,2026-04-26 01:00:00,2026-05-24 13:00:00

The issue you are encountering with corrupted `MIN`/`MAX` results on Iceberg tables partitioned by

hour(data_timestamp)

is a known bug related to the MetaScan optimization (controlled by the variable

enable_rewrite_simple_agg_to_meta_scan

). In StarRocks, when this optimization is enabled, the engine attempts to read the `min`/`max` values directly from the Iceberg manifest file statistics to avoid a full table scan. However, for "hidden" partitions like

hour()

, Iceberg internally stores partition values as integers (representing the number of hours since the epoch). If the MetaScan rule reads these integers but treats them as raw strings or fails to correctly transform them back to the original

datetime

type, you see corrupted outputs like

93-11-24

and the JDBC driver throws a

NumberFormatException

. Fix Status in 4.0 and 4.1 While a general fix for "Iceberg min/max value typing" (Issue #65551) was included in the StarRocks 4.0.x line, specifically for the

hour

and

date

transforms, additional fixes were required to ensure correct decoding across all metadata paths. * StarRocks 4.0 Branch: You are currently on v4.0.10, which contains the initial typing fix. However, some edge cases related to partition transforms were still being resolved in very recent PRs (e.g., #71863 and #71913, fixed in May 2026). These are expected to be fully stable in v4.0.11 and later. * StarRocks 4.1 Branch: This branch includes more comprehensive improvements to the Iceberg metadata scanning and statistics cache. If you upgrade to v4.1.1 or later, the issue should be resolved as it incorporates the latest logic for handling transformed partition metadata. Recommended Action 1. Upgrade: Check if v4.1.1 or v4.0.11 is available in your environment. These versions include the most recent fixes for Iceberg manifest statistics handling. 2. Persistent Workaround: Continue to disable the MetaScan optimization for these specific queries. You can do this at the session level:

sql
    SET enable_rewrite_simple_agg_to_meta_scan = false;
    -- Note: enable_min_max_optimization is an alias for this in some versions.

3. Verify Stats: Ensure that the statistics in the Iceberg manifests themselves are not corrupted (you can check this via Iceberg's

$files

metadata table or using Spark/Trino) to rule out an ingestion-side issue. If the problem persists after moving to v4.1.1+, it is likely a specific regression for the

hour

transform, and we recommend providing a query profile to the StarRocks community for further analysis. References • administration/management/FE_configuration.md • sql-reference/System_variable.md • using_starrocks/async_mv/use_cases/query_rewrite_with_materialized_views.md • using_starrocks/sorted_aggregate.md • using_starrocks/async_mv/feature-support-asynchronous-materialized-views.md

please file a bug and maybe tag pr 71870 and @dirtysalt

@Евгений Шишкин wasn't it fixed in 4.1 branch? or this is a new issue ?

idk, hard to reason without test file