prestodb/presto · error · UnknownTableTypeException

Not an Iceberg table: ${getSchemaTableName()}

Error message

Not an Iceberg table: ${getSchemaTableName()}

What it means

HiveTableOperations.refresh loads the Hive-metastore-backed table and requires it to be an Iceberg table (detected via table properties). If the underlying Hive table exists but is not an Iceberg table, refresh throws UnknownTableTypeException with 'Not an Iceberg table: <schema.table>'. Called by current() and metadata(), so any Iceberg operation on this table fails.

Source

Thrown at presto-iceberg/src/main/java/com/facebook/presto/iceberg/HiveTableOperations.java:216

    {
        if (shouldRefresh) {
            return refresh();
        }
        return currentMetadata;
    }

    @Override
    public TableMetadata refresh()
    {
        if (location.isPresent()) {
            refreshFromMetadataLocation(null);
            return currentMetadata;
        }

        Table table = getTable();

        if (!isIcebergTable(table)) {
            throw new UnknownTableTypeException("Not an Iceberg table: " + getSchemaTableName());
        }

        if (isPrestoView(table)) {
            throw new TableNotFoundException(new SchemaTableName(database, tableName));
        }

        String metadataLocation = table.getParameters().get(METADATA_LOCATION);
        if (metadataLocation == null) {
            throw new PrestoException(ICEBERG_INVALID_METADATA, format("Table is missing [%s] property: %s", METADATA_LOCATION, getSchemaTableName()));
        }

        refreshFromMetadataLocation(metadataLocation);

        return currentMetadata;
    }

    @Override
    public void commit(@Nullable TableMetadata base, TableMetadata metadata)

View on GitHub (pinned to 55bb57d202)

Solutions

1. Query the table through the correct connector/catalog (use the hive catalog for plain Hive tables).
2. If it should be Iceberg, migrate it (e.g. Hive-to-Iceberg migration procedure) so table_type=ICEBERG is set.
3. Check catalog config (iceberg.catalog.type / hive.metastore mapping) so names resolve to the intended catalog.
4. Confirm the metastore's table parameters still contain the Iceberg markers; re-run migration if a job stripped them.

Example fix

-- before: SELECT * FROM iceberg.default.my_hive_table; -- Not an Iceberg table
-- after: use correct catalog, or migrate
SELECT * FROM hive.default.my_hive_table;
-- or in Spark: CALL catalog.system.migrate('default.my_hive_table');

Table t = metastore.getTable(db, name);
if (t == null || !"ICEBERG".equalsIgnoreCase(t.getParameters().get("table_type"))) {
  throw new IllegalStateException("Not an Iceberg table: " + db + "." + name + " — use the correct catalog");
}

boolean isIceberg(Table t) { return t != null && t.getParameters() != null && "ICEBERG".equalsIgnoreCase(t.getParameters().get("table_type")); }

try { icebergOps.refresh(); } catch (UnknownTableTypeException e) { /* fall back to hive connector or migrate table */ }

When it happens

Trigger: Any Iceberg read/commit path touching a Hive table that lacks the Iceberg table_type property — e.g. pointing the Iceberg connector at a plain Hive table, wrong catalog mapping, or the table was converted away from Iceberg after caching.

Common situations: Catalog misconfiguration (table registered in both hive and iceberg catalogs), user querying a legacy Hive table through the Iceberg connector, a migration that reverted the table_type property, schema/table name collision across catalogs.

Related errors

• Not a Hive table:
• NOT_SUPPORTED
• Table not found: ${new SchemaTableName(database, tableName)}
• NOT_SUPPORTED
• Expected all parameters to be named type, but got %s

AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04). Data as JSON: /api/errors/7fcae0cf360b1806. Report an issue: GitHub.