prestodb/presto · error · SemanticException

VIEW_ANALYSIS_ERROR

VIEW_ANALYSIS_ERROR

Error message

Failed analyzing stored view '%s': %s

What it means

When a query references a stored view, Presto re-analyzes the view's stored SQL. If that analysis fails with a non-PrestoException RuntimeException, it is wrapped as VIEW_ANALYSIS_ERROR so the user sees which view failed and why. Common inner causes: referenced tables/columns dropped or renamed, permission changes, or type invalidation since the view was created.

Source

Thrown at presto-main-base/src/main/java/com/facebook/presto/sql/analyzer/StatementAnalyzer.java:5227

                if (owner.isPresent() && !owner.get().equals(session.getIdentity().getUser())) {
                    // definer mode
                    identity = new Identity(owner.get(), Optional.empty(), emptyMap(), session.getIdentity().getExtraCredentials(), emptyMap(), Optional.empty(), session.getIdentity().getReasonForSelect(), emptyList());
                    viewAccessControl = new ViewAccessControl(accessControl);
                }
                else {
                    identity = session.getIdentity();
                    viewAccessControl = accessControl;
                }

                Session viewSession = createViewSession(catalog, schema, identity);

                StatementAnalyzer analyzer = new StatementAnalyzer(analysis, metadata, sqlParser, viewAccessControl, viewSession, warningCollector);
                Scope queryScope = analyzer.analyze(query, Scope.create());
                return queryScope.getRelationType().withAlias(name.getObjectName(), null);
            }
            catch (RuntimeException e) {
                throwIfInstanceOf(e, PrestoException.class);
                throw new SemanticException(VIEW_ANALYSIS_ERROR, e, node.getLocation(), "Failed analyzing stored view '%s': %s", name, e.getMessage());
            }
        }

        private Session createViewSession(Optional<String> catalog, Optional<String> schema, Identity identity)
        {
            Session.SessionBuilder viewSessionBuilder = Session.builder(metadata.getSessionPropertyManager())
                    .setQueryId(session.getQueryId())
                    .setRuntimeStats(session.getRuntimeStats())
                    .setTransactionId(session.getTransactionId().orElse(null))
                    .setIdentity(identity)
                    .setSource(session.getSource().orElse(null))
                    .setCatalog(catalog.orElse(null))
                    .setSchema(schema.orElse(null))
                    .setTimeZoneKey(session.getTimeZoneKey())
                    .setLocale(session.getLocale())
                    .setRemoteUserAddress(session.getRemoteUserAddress().orElse(null))
                    .setUserAgent(session.getUserAgent().orElse(null))
                    .setClientInfo(session.getClientInfo().orElse(null))

View on GitHub (pinned to 55bb57d202)

Solutions

  1. Read the wrapped inner message to find the real failure (missing table/column/function)
  2. DROP and recreate the view against the current schema
  3. Restore the missing base table/column or correct the view's SQL via ALTER VIEW/CREATE OR REPLACE VIEW
  4. Fix permissions so the view owner can access the underlying objects

Example fix

-- before (broken view referencing dropped column)
CREATE VIEW v AS SELECT old_col FROM t;
-- after
CREATE OR REPLACE VIEW v AS SELECT new_col FROM t;
Defensive patterns

Strategy: try-catch

Validate before calling

// Periodically re-validate stored views:
SELECT * FROM system.metadata.views -- then run each view's definition
-- or: SELECT * FROM <view> LIMIT 0; to detect breakage early

Try / catch

try { return session.execute("SELECT * FROM " + viewName); }
catch (SemanticException e) {
    if (e.getCode() == VIEW_ANALYSIS_ERROR) {
        log.error("View {} broken: {}", viewName, e.getCause().getMessage());
        // rebuild or fail over
    } else { throw e; }
}

Prevention

When it happens

Trigger: `SELECT * FROM catalog.schema.view` where the view's underlying table was dropped/renamed, a column's type changed incompatibly, the view body references a missing function, or the caller lacks privileges (analyzed under a view access control); thrown in analyzeView of StatementAnalyzer.

Common situations: Schema drift: upstream tables changed after CREATE VIEW; revoked permissions on the base table; connector catalog changes; stale view definitions after migrations.

Related errors


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