prestodb/presto · error · PrestoException

QUERY_REJECTED

QUERY_REJECTED

Error message

Table ${schemaTableName} has no range partition

What it means

KuduClientSession.changeRangePartition attempts to ALTER a table's range partitions (add or drop). It throws QUERY_REJECTED when the table's partition design contains no range partition definition, because adding/removing a range is meaningless for a hash-only table.

Source

Thrown at presto-kudu/src/main/java/com/facebook/presto/kudu/KuduClientSession.java:358

    }

    public void dropRangePartition(SchemaTableName schemaTableName, RangePartition rangePartition)
    {
        reTryKerberos(kerberosAuthEnabled);
        changeRangePartition(schemaTableName, rangePartition, RangePartitionChange.DROP);
    }

    private void changeRangePartition(SchemaTableName schemaTableName, RangePartition rangePartition,
            RangePartitionChange change)
    {
        try {
            String rawName = schemaEmulation.toRawName(schemaTableName);
            KuduTable table = client.openTable(rawName);
            Schema schema = table.getSchema();
            PartitionDesign design = KuduTableProperties.getPartitionDesign(table);
            RangePartitionDefinition definition = design.getRange();
            if (definition == null) {
                throw new PrestoException(QUERY_REJECTED, "Table " + schemaTableName + " has no range partition");
            }
            PartialRow lowerBound = KuduTableProperties.toRangeBoundToPartialRow(schema, definition, rangePartition.getLower());
            PartialRow upperBound = KuduTableProperties.toRangeBoundToPartialRow(schema, definition, rangePartition.getUpper());
            AlterTableOptions alterOptions = new AlterTableOptions();
            switch (change) {
                case ADD:
                    alterOptions.addRangePartition(lowerBound, upperBound);
                    break;
                case DROP:
                    alterOptions.dropRangePartition(lowerBound, upperBound);
                    break;
            }
            client.alterTable(rawName, alterOptions);
        }
        catch (KuduException e) {
            throw new PrestoException(GENERIC_INTERNAL_ERROR, e);
        }
    }

View on GitHub (pinned to 55bb57d202)

Solutions

1. Verify the table has range partitioning (partition_by_range_columns) before altering ranges
2. Recreate the table with a range partition definition if ranges are required
3. Skip hash-only tables in partition-maintenance scripts

Example fix

-- before
ALTER TABLE kudu.events ADD RANGE PARTITION VALUE = '2026-01-01';
-- after (recreate table with)
WITH (partition_by_hash_columns = ARRAY['id'], partition_by_range_columns = ARRAY['day'])

SHOW CREATE TABLE kudu.my_table; -- confirm partition_by_range_columns is present before ALTER ... RANGE PARTITION

try {
    clientSession.addRangePartition(name, rangePartition);
} catch (PrestoException e) {
    if (e.getErrorCode() == KuduErrorCode.QUERY_REJECTED && e.getMessage().contains("has no range partition")) {
        throw new IllegalStateException("Table is hash-only; recreate with range partitioning", e);
    }
    throw e;
}

When it happens

Trigger: Running ALTER TABLE ... ADD RANGE / DROP RANGE PARTITION on a Kudu table created with only hash partitions (or no explicit range partitioning).

Common situations: Admins managing range-partitioned tables by date forget the target table was created with partition_by_hash_columns only; scripts applying range maintenance to many tables hit the hash-only ones.

Related errors

• GENERIC_USER_ERROR
• HIVE_COLUMN_ORDER_MISMATCH
• GENERIC_INTERNAL_ERROR
• ALREADY_EXISTS
• INVALID_VIEW

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