@Rocky is there any workaround for https://github.com/StarRocks/starrocks/issues/71211 - there is a PR to fix it, but seems to be taking an eternity to get merged and it is a blocker for us.

Based on my search of the current StarRocks documentation and public GitHub records as of June 2026, I couldn't find a specific entry for Issue #71211 or a corresponding PR by that exact number. The StarRocks project recently merged and released several significant fixes in the 71,000–73,000 range (for instance, Issue #71992 regarding transaction log drops in shared-data mode). However, without the title or a description of the symptoms, it is difficult to confirm if a specific workaround exists for your situation. To help me find a workaround or the status of the fix, could you provide: 1. The title of the issue or the specific error message you are seeing. 2. The area of the database it affects (e.g., Primary Key tables, Materialized Views, Routine Load, or a specific External Catalog like Iceberg/Hudi). General Advice for Blockers with Pending PRs: If you are blocked by a fix that is technically complete but pending a merge: * Backport/Cherry-pick: If you are running on a specific version (e.g., 3.4.x or 3.5.x), check if the PR has a corresponding "backport" label. Sometimes the main PR takes time to merge into

main

but backports to stable branches move faster. * Community Build: In urgent cases, some users build a custom version of the StarRocks BE/FE by cherry-picking the specific PR branch into their current stable release branch. * Slack/Forum: If you haven't already, ping the PR author or a maintainer in the

#starrocks-dev

channel on the StarRocks Community Slack. Mentioning that it is a production blocker usually helps escalate the review. If you can share the symptoms or the PR title, I can search for alternative configurations or "hidden" flags that might mitigate the issue in the meantime. References • developers/versions.md • using_starrocks/caching/block_cache.md • developers/How_to_Contribute.md • integrations/smt/starrocks_sqlalchemy.md • release_notes/release-3.4.md

@Rocky this is the PR that will close the issue https://github.com/StarRocks/starrocks/pull/71295

Based on the PR you shared (#71295), this work is part of the Unified IVM (Incremental View Maintenance) Framework and specifically adds the

IvmRewriter

and scan/filter/project rules for Iceberg. Since this PR is still open and adds foundational rules for row-level/snapshot-level incremental refresh for Iceberg catalogs, there is no direct "switch" to enable this specific logic until it is merged. However, depending on your use case, there are several standard workarounds to achieve incremental-like behavior for Iceberg in the meantime: 1. Use Partitioned Refresh (Partition Change Tracking) The existing "coarse-grained" incremental refresh in StarRocks relies on Partition Change Tracking (PCT). If your Iceberg table is partitioned (e.g., by date), you can create a partitioned Materialized View (MV) and refresh it by partition. * Requirement: Both the Iceberg base table and the StarRocks MV must be partitioned on the same column (or a derivative like

date_trunc

). * Command:

REFRESH MATERIALIZED VIEW <mv_name> PARTITION (START("2024-01-01") END("2024-01-02"))

. * Behavior: StarRocks will only recompute the specified partitions rather than the entire table. 2. Manual "High Watermark" ETL If you cannot use partitioned MVs (e.g., your data isn't partitioned or the logic is too complex for PCT), you can simulate incremental maintenance using a scheduled

INSERT INTO ... SELECT

task: * Identify a "tracking column" in your Iceberg table (like

updated_at

or

event_time

). * Create a standard StarRocks table to hold the results. * Run a scheduled task (using an external orchestrator or StarRocks' internal

INSERT INTO

scheduled tasks) that only selects rows where

tracking_column > (SELECT max(tracking_column) FROM target_table)

. 3. Incremental Scan via Session Variables There are experimental flags that control the incremental planning framework, though they may not be fully functional for Iceberg without the specific rules in the pending PR: *

SET enable_incremental_mv = true;

(Introduced in v3.2.0, this enables the planning phase for incremental refresh). *

SET enable_connector_incremental_scan_ranges = true;

(Useful for external catalogs to read deltas). _ _Note: These likely won't solve the "IvmRewriter" requirement in PR #71295, but they are the toggles used for the new framework.* 4. Direct Iceberg Snapshot Queries If you need to manually find what changed to perform your own updates, you can use StarRocks' Time Travel features for Iceberg (available since v3.4.0) to compare snapshots:

sql
-- Query data as of a specific snapshot
SELECT * FROM iceberg_table FOR SYSTEM_VERSION AS OF <snapshot_id>;

Recommendation: If you are strictly blocked because you need automatic row-level delta tracking for Iceberg MVs (which is what PR #71295 provides), the current production-ready workaround is to use Partitioned MVs (PCT) if possible. If your logic requires row-level deltas and cannot wait for the merge, you may need to implement a manual "Insert Overwrite" pipeline that filters the Iceberg data by timestamp/ID. If you have a specific error message or a specific SQL pattern that is failing, I can check if there's a more targeted configuration change.

@Rocky, the issue that I'm trying to work around is

GRANT ALL ON ALL VIEWS IN DATABASE fails with cannot find db: <db_name> when
the current session is connected to an external catalog (e.g., Iceberg via REST).
The equivalent GRANT ALL ON ALL TABLES IN DATABASE works correctly.

This happens because ViewPEntryObject and MaterializedViewPEntryObject resolve
databases exclusively through the local (internal) metastore, while
TablePEntryObject already has catalog-aware resolution that supports external
catalogs.

Is there a workaround?

The issue you are encountering with

GRANT ALL ON ALL VIEWS IN DATABASE

failing in external catalogs (due to non-catalog-aware resolution in

ViewPEntryObject

) has a few practical workarounds depending on the level of automation you need. 1. Use

ALL TABLES

(Recommended) In StarRocks, especially for external catalogs like Iceberg or Hive, the permission system often treats views and tables as the same object type (Table) within the external metastore. The official documentation for Hive and Iceberg catalogs explicitly states that to grant privileges on both tables and views, you should use the

ALL TABLES

syntax. For example:

sql
SET CATALOG <your_iceberg_catalog>;
GRANT SELECT ON ALL TABLES IN DATABASE <db_name> TO ROLE <role_name>;

The documentation notes that this command grants the privilege to query all tables and all views in that external catalog database. Since you confirmed that the

ALL TABLES

version of the command works correctly, this is the most direct workaround. 2. Use Three-Part Names from

default_catalog

The bug you described is triggered when the session's current catalog is an external one. You may be able to bypass the faulty resolution by switching back to the internal catalog and using a fully qualified database name:

sql
SET CATALOG default_catalog;
-- Use <catalog>.<database> to specify the target
GRANT ALL ON ALL VIEWS IN DATABASE <your_iceberg_catalog>.<db_name> TO ROLE <role_name>;

Note: This depends on whether the parser handles the "ALL VIEWS" list resolution correctly when the database name is cross-catalog. 3. Grant at the Database Level Instead of granting on

ALL VIEWS

(which specifies the object type), grant the permissions on the

DATABASE

itself. This typically covers all objects within that database without requiring the specific resolution of the

VIEW

entry objects:

sql
SET CATALOG <your_iceberg_catalog>;
GRANT ALL ON DATABASE <db_name> TO ROLE <role_name>;

4. Individual View Grants If the bulk "ALL" commands continue to fail, individual grants are known to be catalog-aware and should work as long as you provide the database prefix:

sql
-- This syntax is catalog-aware
GRANT SELECT ON VIEW <db_name>.<view_name> TO ROLE <role_name>;

Summary of the " eternity" (PR #71295) The PR you mentioned (#71295) is part of a large architectural shift toward a Unified IVM (Incremental View Maintenance) framework. Because it touches core rewriter and planner rules for external catalogs, it undergoes much stricter review than standard bug fixes. Using the

ALL TABLES

syntax is the intended way to manage these permissions in the current v3.x privilege model until that unified logic is finalized. References • sql-reference/sql-statements/account-management/GRANT.md • administration/user_privs/authorization/User_privilege.md • data_source/catalog/hive_catalog.md