Doris-Breakwater commented on issue #69367: URL: https://github.com/apache/doris/issues/69367#issuecomment-6308667238
Breakwater-GitHub-Analysis-Slot: slot_afbd53d196e7 This is actionable as an FE synchronous-MV DDL handling defect: the shared grammar accepts `IF NOT EXISTS`, but the synchronous command drops that information. Whether synchronous MVs should support the clause or explicitly reject it remains a maintainer API decision; silently ignoring it is the inconsistency. Suggested ownership: FE/Nereids parser and synchronous materialized views. The issue currently has no labels. I checked the exact reported 4.1.3 commit, `7126cf65d96ebc43fce0906f51e92c1a2ccf24a6`, and master commit `9e60fab4db00998d490d916c4bf304b15490c1b9`. The following is verified from source, rather than an independent execution of the Docker reproduction: - The [4.1.3 grammar](https://github.com/apache/doris/blob/7126cf65d96ebc43fce0906f51e92c1a2ccf24a6/fe/fe-core/src/main/antlr4/org/apache/doris/nereids/DorisParser.g4#L78) accepts `(IF NOT EXISTS)?` in the shared MV production. [LogicalPlanBuilder](https://github.com/apache/doris/blob/7126cf65d96ebc43fce0906f51e92c1a2ccf24a6/fe/fe-core/src/main/java/org/apache/doris/nereids/parser/LogicalPlanBuilder.java#L1630) routes the supplied statements to `visitCreateSyncMvCommand`, which passes only the name, query plan and properties. [CreateMaterializedViewCommand](https://github.com/apache/doris/blob/7126cf65d96ebc43fce0906f51e92c1a2ccf24a6/fe/fe-core/src/main/java/org/apache/doris/nereids/trees/plans/commands/CreateMaterializedViewCommand.java#L106) has no existence flag and always validates, then calls the creation path. The [reported master parser](https://github.com/apache/doris/blob/9e60fab4db00998d490d916c4bf304b15490c1b9/fe/fe-core/src/main/java/org/apache/doris/nereids/parser/Log icalPlanBuilder.java#L1666) and synchronous command retain this behavior. This does not establish the behavior of later commits. - The execution chain is `CreateMaterializedViewCommand.run` → `Env.createMaterializedView` → `Alter.processCreateMaterializedView` → `MaterializedViewHandler.processCreateMaterializedView`. In the [4.1.3 handler](https://github.com/apache/doris/blob/7126cf65d96ebc43fce0906f51e92c1a2ccf24a6/fe/fe-core/src/main/java/org/apache/doris/alter/MaterializedViewHandler.java#L194), the table-wide duplicate-column check runs **before** the MV-name check. MV aliases become stored column names, and [OlapTable.rebuildFullSchema](https://github.com/apache/doris/blob/7126cf65d96ebc43fce0906f51e92c1a2ccf24a6/fe/fe-core/src/main/java/org/apache/doris/catalog/OlapTable.java#L540) includes materialized-index columns. Reusing `mv_k1` therefore reaches `ERR_DUP_FIELDNAME` first. With the second query's distinct aliases, execution reaches [checkAndPrepareMaterializedView](https://github.com/apache/doris/blob/7126cf65d96ebc43fce0906f51e92c1a2ccf24a6/fe/fe-core/src/main/java/org/apache/doris/alter/ MaterializedViewHandler.java#L525), where `hasMaterializedIndex("mv1")` unconditionally throws the reported “already exists” error. The two messages are consistent with this validation order, rather than evidence of two separate root causes. - The asynchronous branch preserves `ctx.EXISTS() != null` through `CreateMTMVInfo` into `CreateTableInfo`; [InternalCatalog](https://github.com/apache/doris/blob/7126cf65d96ebc43fce0906f51e92c1a2ccf24a6/fe/fe-core/src/main/java/org/apache/doris/datasource/InternalCatalog.java#L1238) explicitly returns success for an existing table when that flag is set. Synchronous MVs use the base table's materialized-index namespace, so the corresponding check must use that namespace rather than a database-level table lookup. Recommended next step: choose and document the synchronous-MV contract. If supporting the requested no-op, propagate the flag into the synchronous command and perform the existing-name decision under the base-table metadata lock before creation-specific column validation or job creation, preserving authorization checks and cleanup. Merely changing the later “already exists” exception would leave the identical-query case failing earlier. If the clause is unsupported, reject it explicitly when routing to the synchronous command while retaining asynchronous support. Regression coverage should include first creation with the clause; both supplied retries after `FINISHED`; retries without the clause still failing; and asynchronous/table behavior remaining intact. For successful retries, verify that the existing index ID and definition remain unchanged and that no additional rollup job is submitted. Also define/test concurrent or in-progress creation and collisions with base-index/rollup names, since `hasMaterializedIndex` checks the shared index map. No additional version, SQL, profile or broad log collection is needed for initial triage: the report already supplies the build, DDL, errors and completion condition. The remaining validation gap is running the exact reproduction and proposed regression tests on the affected build and any candidate fix. If results differ, collect `SELECT VERSION()`, session planner settings, `SHOW CREATE TABLE t`, `SHOW ALTER TABLE MATERIALIZED VIEW FROM repro`, and the FE exception stack for the failed statement. The existing drop/recreate workaround rebuilds the MV and is not an equivalent no-op. No repository code was changed during this analysis. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
