prestodb/presto · error · SemanticException

MISSING_SCHEMA

MISSING_SCHEMA

Error message

Schema '%s' does not exist

What it means

SemanticException thrown by RenameSchemaTask when the source schema does not exist in the (validated) catalog. metadataResolver.schemaExists(source) returning false aborts the rename, since there is nothing to rename. The catalog was already validated, so this is specifically a missing schema.

Source

Thrown at presto-main-base/src/main/java/com/facebook/presto/execution/RenameSchemaTask.java:58

    @Override
    public String getName()
    {
        return "RENAME SCHEMA";
    }

    @Override
    public ListenableFuture<?> execute(RenameSchema statement, TransactionManager transactionManager, Metadata metadata, AccessControl accessControl, Session session, List<Expression> parameters, WarningCollector warningCollector, String query)
    {
        CatalogSchemaName source = createCatalogSchemaName(session, statement, Optional.of(statement.getSource()), metadata);
        CatalogSchemaName target = new CatalogSchemaName(source.getCatalogName(), statement.getTarget().getValue());
        MetadataResolver metadataResolver = metadata.getMetadataResolver(session);

        if (!metadataResolver.catalogExists(source.getCatalogName())) {
            throw new SemanticException(MISSING_CATALOG, "Catalog '%s' does not exist", source.getCatalogName());
        }

        if (!metadataResolver.schemaExists(source)) {
            throw new SemanticException(MISSING_SCHEMA, statement, "Schema '%s' does not exist", source);
        }

        if (metadataResolver.schemaExists(target)) {
            throw new SemanticException(SCHEMA_ALREADY_EXISTS, statement, "Target schema '%s' already exists", target);
        }

        accessControl.checkCanRenameSchema(session.getRequiredTransactionId(), session.getIdentity(), session.getAccessControlContext(), source, statement.getTarget().getValue());

        metadata.renameSchema(session, source, statement.getTarget().getValue());

        return immediateFuture(null);
    }
}

View on GitHub (pinned to 55bb57d202)

Solutions

1. Verify with SHOW SCHEMAS FROM catalog that the source schema exists
2. Make the migration idempotent: check information_schema or skip if the target schema already exists
3. Correct the schema name spelling/case in the statement
4. Confirm you're renaming in the intended catalog/environment

Example fix

-- before
ALTER SCHEMA sales.web RENAME TO web_archive; -- second run: web already renamed
-- after
-- guard in migration runner
SELECT count(*) FROM information_schema.schemata WHERE schema_name='web'; -- skip rename if 0
ALTER SCHEMA sales.web RENAME TO web_archive;

ResultSet rs = stmt.executeQuery("SHOW SCHEMAS FROM sales");
Set<String> schemas = new HashSet<>();
while (rs.next()) schemas.add(rs.getString("Schema").toLowerCase());
if (!schemas.contains("web")) { /* already renamed or never existed */ }

try {
    execute("ALTER SCHEMA sales.web RENAME TO web_archive");
} catch (SemanticException e) {
    if (e.getCode() == MISSING_SCHEMA && schemaExists("sales.web_archive")) { /* already done — skip */ }
    else throw e;
}

When it happens

Trigger: ALTER SCHEMA catalog.source RENAME TO target where schemaExists(source) is false. Includes typos, wrong-case schema names, and schemas dropped concurrently.

Common situations: Schema already renamed by a prior run of the same script; typo in schema name; schema dropped by cleanup jobs; running migrations against the wrong catalog.

Related errors

• MISSING_TABLE
• MISSING_TABLE
• NOT_SUPPORTED
• MISSING_COLUMN
• MISSING_TABLE

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