• administration/management/monitoring/alert.md • data_source/catalog/hudi_catalog.md

In version 4.0.10, the error you are encountering is a locking hierarchy violation within the StarRocks fine-grained Lock Manager (introduced and matured in the 3.x and 4.x branches). The specific error message

Can't request Database READ Lock ... in the scope of Database INTENTION_SHARED Lock

indicates that the thread executing the query against

information_schema.views

is attempting to "upgrade" its lock in a way the system forbids to prevent deadlocks. Why this happens in v4.0.10 When you query

information_schema.views

, the FE executes

ViewsSystemTable.evaluate()

. This method iterates through all catalogs and databases to collect view metadata. 1. Current Lock: The thread already holds an Intention Shared (IS) lock on a database (likely acquired during the query analysis phase). 2. Requested Lock: While holding that

IS

lock, the logic in

ViewsSystemTable

attempts to acquire a full READ (Shared) lock on the same database to list the views safely. 3. Conflict: In the new Lock Manager, a thread cannot request a stronger lock (READ) on a resource if it already holds an intention lock (IS) on that same resource unless it is handled as a specific lock upgrade. This is currently failing in the metadata collection logic of your version. Troubleshooting and Workarounds 1. Isolate the Database/Catalog: The error usually triggers when the iterator hits a specific database or an external catalog (e.g., Iceberg, Hive). Try to narrow down which database is causing the lock conflict:

sql
    -- Try querying a specific database to see if it bypasses the global collection logic
    SELECT * FROM information_schema.views WHERE table_schema = 'your_db_name';

If this works for some databases but fails for others, the issue might be specific to views referencing External Catalogs or databases with a very high number of views. 2. Use

SHOW

Commands: The

SHOW

commands typically use a different internal path that might not trigger this specific lock hierarchy conflict: *

SHOW VIEWS FROM <db_name>;

*

SHOW CREATE VIEW <db_name>.<view_name>;

3. Check for "Broken" or Circular Views: If a view definition is invalid or has recursive dependencies, the analyzer might repeatedly attempt to acquire locks as it tries to resolve the view's schema, leading to this state. 4. FE Configuration: In version 4.x, the lock manager is core to the system's performance. However, you can check the status of relevant configurations: *

ADMIN SHOW FRONTEND CONFIG LIKE 'lock_manager_enabled';

* If you are in a test environment and this is a total blocker, you could technically set

lock_manager_enabled = false

in

fe.conf

and restart the FE to revert to the old global locking mechanism, but this is not recommended for production as it disables fine-grained locking. Recommendation This appears to be a bug in the metadata analysis logic of version 4.0.10 (specifically in how it handles lock scopes during

information_schema

evaluation). * Search for Patches: Check if there is a version 4.0.11 or 4.1.x available, as locking logic is frequently refined in patch releases. * Report to Community: Since this is an internal

ErrorReportException

, it is best to provide your full FE log and the output of

SELECT current_version();

to the StarRocks GitHub Issues or Slack. Mention that it is a lock upgrade conflict in

ViewsSystemTable.evaluate()

. References • sql-reference/information_schema/views.md • administration/management/FE_configuration.md • sql-reference/sql-statements/View/SHOW_CREATE_VIEW.md

• administration/management/monitoring/alert.md • sql-reference/sys/sys.md • data_source/catalog/unified_catalog.md • sql-reference/information_schema/views.md • administration/management/FE_configuration.md • sql-reference/sql-statements/View/SHOW_CREATE_VIEW.md • administration/management/monitoring/alert.md • sql-reference/sys/sys.md • data_source/catalog/unified_catalog.md