@Rocky does starrocks support granting select view access to db for user account .?

Yes, StarRocks supports granting SELECT access to views at the database level. You can grant this privilege to either a specific user account or a role. Syntax To grant access to all views within a specific database:

sql
GRANT SELECT ON ALL VIEWS IN DATABASE <database_name> TO USER <user_identity>;

To grant access to a specific view:

sql
GRANT SELECT ON VIEW <database_name>.<view_name> TO USER <user_identity>;

Key Considerations * Version 3.4.1+ (Secure Views): * By default (

SECURITY NONE

), a user only needs the

SELECT

privilege on the view itself to query it; they do not need access to the underlying base tables. * If a view is created with

SECURITY INVOKER

, the user must have

SELECT

privileges on both the view and all referenced base tables. * Versions < 3.4.1: Users typically need

SELECT

privileges on both the view and the underlying base tables to perform queries. * Catalogs: Before running the

GRANT

command, ensure you have set the correct catalog (e.g.,

SET CATALOG default_catalog;

). * External Views: Starting from v3.1, you can also grant

SELECT

privileges on Hive table views in external catalogs. Example

sql
-- Grant select on all views in 'sales_db' to user 'john'
GRANT SELECT ON ALL VIEWS IN DATABASE sales_db TO USER 'john'@'%';

You can verify granted privileges by querying the

sys.grants_to_users

view or using:

sql
SHOW GRANTS FOR <user_identity>;

References • sql-reference/sql-statements/View/CREATE_VIEW.md • administration/user_privs/authorization/privilege_item.md • table_design/table_design.md • administration/user_privs/authorization/user_privs.md • administration/user_privs/authorization/privilege_faq.md • administration/user_privs/authorization/User_privilege.md

@Rocky should I select the catalog and then then run the grant command ? Eventhough database exist, it still saying db doesn't exist.

Yes, you must select the catalog using

SET CATALOG

before running the

GRANT

command on a database. In StarRocks, the

GRANT

statement for databases and their child objects (tables, views, etc.) is context-aware. If you do not explicitly set the catalog, StarRocks may look for the database in the wrong catalog (even if you are trying to grant to the

default_catalog

), leading to the "database doesn't exist" error. Recommended Steps 1. Set the catalog context (usually

default_catalog

for internal data):

sql
    SET CATALOG default_catalog;

2. Run the grant command:

sql
    GRANT SELECT ON ALL VIEWS IN DATABASE <your_db_name> TO USER 'user_name'@'%';

Why this happens * Catalog Context: The

GRANT ... ON DATABASE

syntax does not always support fully qualified names like

GRANT ... ON DATABASE catalog.db

. It expects the database name relative to the current session's catalog. * External Catalogs: If your views are in an external catalog (like Hive or Iceberg), you must switch to that catalog first:

sql
    SET CATALOG hive_catalog;
    GRANT SELECT ON ALL VIEWS IN DATABASE external_db TO USER 'user_name'@'%';

Troubleshooting Tip If you are still getting the error after setting the catalog, verify the database exists in the current catalog by running:

sql
SHOW DATABASES;

If the database name is not in that list, the

GRANT

command will fail. References • sql-reference/sql-statements/account-management/GRANT.md • data_source/catalog/hive_catalog.md • administration/user_privs/authorization/privilege_item.md References • sql-reference/sql-statements/account-management/GRANT.md • data_source/catalog/hive_catalog.md • administration/user_privs/authorization/privilege_item.md

@Rocky whenever I run GRANT SELECT ON ALL TABLES IN DATABASE, its running without any errors, however whn I run it for all views GRANT SELECT ON ALL VIEWS IN DATABASE, it says DB not found. The error seems to be wrong.

The syntax you are using is technically correct for StarRocks v3.0 and later, but the "DB not found" error specifically for views (while tables work) often points to one of three things: a catalog context mismatch, a specific bug in certain versions, or a lack of views in that database. 1. Ensure Catalog Context Even if you are in the "default" catalog, the

ALL VIEWS

parser in some versions is stricter than the

ALL TABLES

parser. Always explicitly set the catalog before running the grant:

sql
SET CATALOG default_catalog;
GRANT SELECT ON ALL VIEWS IN DATABASE <your_db_name> TO USER 'user_name'@'%';

2. Known "DB Not Found" Bug There is a known issue in some StarRocks 3.x versions (specifically around 3.1.x and 3.2.x) where the

GRANT ... ON ALL VIEWS

or

ALL MATERIALIZED VIEWS

command fails to resolve the database correctly, even when the same command for

ALL TABLES

succeeds. * Workaround: Try qualifying the database name with the catalog or using backticks:

sql
    GRANT SELECT ON ALL VIEWS IN DATABASE `your_db_name` TO USER 'user_name'@'%';

* Check your version: If you are on an early 3.x release, this was likely fixed in a later patch (e.g., v3.1.4+ or v3.2.1+). 3. Database Must Exist in Current Catalog The

GRANT

command for views requires that the database be "visible" in the current catalog. Verify visibility by running:

sql
SHOW DATABASES;

If your database is in an External Catalog (like Hive or Iceberg), you must

SET CATALOG <external_catalog_name>

first. Note that for external catalogs, StarRocks only supports granting

SELECT

on Hive views starting from v3.1. 4. Alternative: Granting via Role If the direct user grant continues to fail due to the parser error, try creating a role, granting the privilege to the role, and then assigning the role to the user:

sql
CREATE ROLE view_reader;
GRANT SELECT ON ALL VIEWS IN DATABASE <your_db_name> TO ROLE view_reader;
GRANT view_reader TO USER 'user_name'@'%';

Note: In StarRocks,

SELECT

is a table/view-level privilege. You cannot run

GRANT SELECT ON DATABASE <db>

because

SELECT

is not a valid privilege for the

DATABASE

object type (only

ALTER

,

DROP

,

CREATE TABLE

, etc., are). You must use the

ON ALL VIEWS IN DATABASE

syntax. References • sql-reference/sql-statements/account-management/GRANT.md • administration/user_privs/authorization/privilege_faq.md • administration/user_privs/authorization/privilege_item.md References • sql-reference/sql-statements/account-management/GRANT.md • administration/user_privs/authorization/privilege_faq.md • sql-reference/sys/grants_to_users.md

@Rocky in audit log I see planMemCosts, is the value in planMemCosts is in bytes or kilo bytes .?

In StarRocks, the value in the

planMemCosts

field of the audit log is in bytes. This field represents the estimated (or actual, depending on the version/context) memory consumed by the FE (Frontend) during the query planning phase. Key Details: * Unit: Bytes. * Introduction: This field was introduced in StarRocks v3.1.4 to help administrators monitor and control resource usage during the planning stage. * Purpose: It is often used in Resource Group classifiers (

plan_mem_cost_range

) to route queries to different resource groups based on how "heavy" the planning phase is expected to be. If you are using the

AuditLoader

plugin to sync your logs into a table, the column definition for

planMemCosts

is typically

DOUBLE

or

BIGINT

, and the values you see (e.g.,

254354

) are in bytes (~254 KB). References • administration/management/logs.md • administration/management/audit_loader.md • administration/management/resource_group.md • sql-reference/sql-statements/Resource_Group/CREATE_RESOURCE_GROUP.md References • best_practices/audit_log_resource_group.md • administration/management/logs.md • faq/operation_maintenance_faq.md • administration/management/FE_configuration.md • knowledge/usage/best-practice.md

@Rocky I already have DB in external catalog, when I retry to run create db if not exist, its failing with namespace already exists. however I have another db in default catalog, when I run create db if not exist, it doesn't throw any error. why is this inconsistency between the same command. is it the bug with starrocks .?

The inconsistency you're seeing is a known behavior (and essentially a limitation) in how StarRocks handles metadata operations for External Catalogs compared to the Internal (default_catalog). Why this happens * Internal Catalog (default_catalog): StarRocks has complete control over its own metadata. When you run

CREATE DATABASE IF NOT EXISTS

, the Frontend (FE) checks its internal metadata store first. If the database exists, it simply does nothing and returns success. * External Catalog (e.g., Iceberg, Hive): StarRocks acts as a proxy. When you run

CREATE DATABASE

, StarRocks sends a "Create Namespace" or "Create Database" request to the external service (such as an Iceberg REST Catalog, AWS Glue, or Hive Metastore). * The Error: Many external metadata services (especially Iceberg REST) return a 409 Conflict error with the message "namespace already exists" if you try to create a database that's already there. * The Inconsistency: While the StarRocks parser supports the

IF NOT EXISTS

syntax, in certain versions, the FE does not "catch" and ignore that specific error returned by the external service. Instead, it propagates the raw error from the external catalog back to you, leading to the failure. Is it a bug? It is considered an inconsistency in the implementation of the

IF NOT EXISTS

clause for external catalogs. In the internal catalog, the check is handled locally; in external catalogs, the "check" depends on StarRocks either verifying existence beforehand or correctly handling the "already exists" error code from the remote API, which is not yet uniform across all external catalog types. Recommended Workarounds 1. Check Before Execution: If you are running this in a script or pipeline, check if the database exists first:

sql
    SHOW DATABASES FROM your_external_catalog LIKE 'your_db_name';

2. Ignore the Error: Since the error message "namespace already exists" confirms the database is already there (which is exactly what

IF NOT EXISTS

is supposed to ensure), you can safely ignore this specific error in your automation scripts. 3. Use Unified Catalog (v3.2+): If you aren't already, ensure you are using the Unified Catalog type for Hive/Iceberg, as metadata operation handling is being more actively standardized there. References • sql-reference/sql-statements/Catalog/CREATE_EXTERNAL_CATALOG.md • data_source/catalog/unified_catalog.md • sql-reference/sql-statements/Database/CREATE_DATABASE.md • faq/data_lake_faq.md References • sql-reference/sql-statements/Catalog/CREATE_EXTERNAL_CATALOG.md • data_source/file_external_table.md • data_source/catalog/unified_catalog.md