prestodb/presto · error · UnsupportedOperationException

dropping a table added/modified in the same transaction is n

Error message

dropping a table added/modified in the same transaction is not supported

What it means

If a table was created or altered earlier in the same transaction, dropping it cannot be represented by the buffered action model (the drop would have to undo a not-yet-committed action), so dropTable throws UnsupportedOperationException. This is an in-transaction state conflict, not a metastore failure.

Source

Thrown at presto-hive-metastore/src/main/java/com/facebook/presto/hive/metastore/SemiTransactionalHiveMetastore.java:474

    public synchronized void dropTable(HdfsContext context, String databaseName, String tableName)
    {
        setShared();
        // Dropping table with partition actions requires cleaning up staging data, which is not implemented yet.
        checkNoPartitionAction(databaseName, tableName);
        SchemaTableName schemaTableName = new SchemaTableName(databaseName, tableName);
        Action<TableAndMore> oldTableAction = tableActions.get(schemaTableName);
        if (oldTableAction == null || oldTableAction.getType() == ActionType.ALTER) {
            tableActions.put(schemaTableName, new Action<>(ActionType.DROP, null, context));
            return;
        }
        switch (oldTableAction.getType()) {
            case DROP:
                throw new TableNotFoundException(schemaTableName);
            case ADD:
            case ALTER:
            case INSERT_EXISTING:
                throw new UnsupportedOperationException("dropping a table added/modified in the same transaction is not supported");
            default:
                throw new IllegalStateException("Unknown action type");
        }
    }

    public synchronized void replaceView(MetastoreContext metastoreContext, String databaseName, String tableName, Table table, PrincipalPrivileges principalPrivileges)
    {
        setExclusive((delegate, hdfsEnvironment) -> {
            MetastoreOperationResult operationResult = delegate.replaceTable(metastoreContext, databaseName, tableName, table, principalPrivileges);
            return buildCommitHandle(new SchemaTableName(databaseName, tableName), operationResult);
        });
    }

    public synchronized void renameTable(MetastoreContext metastoreContext, String databaseName, String tableName, String newDatabaseName, String newTableName)
    {
        setExclusive((delegate, hdfsEnvironment) -> {
            MetastoreOperationResult operationResult = delegate.renameTable(metastoreContext, databaseName, tableName, newDatabaseName, newTableName);
            return buildCommitHandle(new SchemaTableName(databaseName, tableName), operationResult);

View on GitHub (pinned to 55bb57d202)

Solutions

Commit (or abort) the current transaction before dropping the table
Track tables created in-transaction and abort/roll back the transaction instead of issuing dropTable
Move the drop into a separate transaction after commit

Example fix

// before
metastore.createTable(ctx, table, privileges);
metastore.dropTable(ctx, db, tbl, false);
// after
metastore.createTable(ctx, table, privileges);
// to abandon, abort the transaction instead of dropping
metastore.abort();

Defensive patterns

Strategy: validation

Validate before calling

// only drop tables the transaction did not create or alter
if (tablesCreatedOrAlteredInTx.contains(new SchemaTableName(db, tbl))) {
    throw new IllegalStateException("Abort transaction instead of dropping in-transaction table");
}

Try / catch

try {
    metastore.dropTable(ctx, db, tbl, false);
} catch (UnsupportedOperationException e) {
    metastore.abort(); // abandon the whole transaction instead
}

Prevention

Roll back with abort(), not dropTable, for tables created in the same transaction
Track in-transaction DDL per table name
Commit before dropping anything the transaction modified

When it happens

Trigger: Calling dropTable for a table whose existing action in this transaction is ADD, ALTER, or INSERT_EXISTING (e.g. createTable then dropTable, or alterTable then dropTable before commit).

Common situations: Cleanup/rollback logic that drops tables it just created inside the same transaction; retry logic that alters then decides to drop; speculative write jobs that create a table and abandon it in one transaction.

Related errors

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