All Products
Search

This Product

    Hologres:Development permissions

    Document Center

    Hologres:Development permissions

    Last Updated:Mar 26, 2026

    Permission issues can cause errors during Hologres development. This page describes solutions to common permission errors that occur in Hologres instances.

    How do I choose the right Hologres permission model?

    Hologres provides three permission models. Pick one based on how your team uses schemas.

    • Standard PostgreSQL authorization model: The native PostgreSQL permission model. Use this if you're familiar with PostgreSQL permission management and need fine-grained, table-level control — for example, granting and revoking permissions per table and per user.

    • Simple permission model (SPM): A database-level model where all users are assigned to one of three user groups (developer, writer, or viewer). Each group has specific access permissions for objects in any schema within a database. Use SPM if you rarely use schemas for isolation, or if you use schemas only as folders to organize tables.

    • Schema-level permission model (SLPM): Each schema gets its own developer, writer, and viewer user groups, providing schema-level isolation. Use SLPM if your team relies heavily on schema-level permission separation.

    Permission errors

    role "RAM$xxx" does not exist

    The RAM user hasn't been added to the Hologres instance. Grant the user development permissions — including Superuser if needed. See Grant development permissions on an instance to a RAM user.

    After granting permissions, retry the operation to confirm the error is gone.

    password authentication failed for user "xxx"

    This error has two causes depending on how you're logging in:

    Logging in with an AccessKey:

    1. Verify the user exists in the instance. If not, add the user. See User management.

    2. Verify the AccessKey ID and AccessKey secret are correct and not disabled.

    Logging in with a custom account (BASIC account):

    1. Verify the custom account exists in the instance. If not, add it. See User management.

    2. Verify the password is correct.

    permission denied for table xxxx

    The current account doesn't have read access to the table. Fix this based on your permission model:

    • Standard PostgreSQL authorization model: Grant SELECT on the table, replacing p4_UID with the RAM user identifier:

      GRANT SELECT ON TABLE tablename TO "p4_UID";

    • SPM: Add the user to the viewer user group or a higher-permission group. See Use the simple permission model.

    After applying the fix, rerun the query to confirm access is restored.

    FATAL: permission denied for database "xxx" detail: user does not have CONNECT privilege

    The user account exists in the instance but has no development permissions on the database. Grant the required permissions — including Superuser if needed. See Grant development permissions on an instance to a RAM user.

    call spm_enable() fails because of role conflicts

    SPM was previously enabled on this database, leaving residual role information. Run CALL spm_enable ('t'); instead. The 't' flag reuses existing system roles rather than attempting to create new ones, which avoids the conflict.

    current database is NOT in simple privilege mode

    SPM isn't enabled for the database. To enable it:

    1. Check the current status:

      SHOW hg_experimental_enable_spm;

    2. Enable SPM and migrate existing objects to SPM management:

      -- Enable SPM, retaining original roles and permissions
CALL spm_enable ('t');
-- Transfer ownership of existing objects to the developer role
CALL spm_migrate ();

      The 't' parameter retains original system roles and their permissions instead of removing them when you run spm_disable. Without it, a subsequent spm_enable() call fails with a role conflict. The spm_enable ('t') command ignores this conflict and reuses the existing system roles.

    must be the owner of table xxxx

    The current user isn't the table owner and can't create child partitions or delete the table. Fix this based on your permission model:

    • Standard PostgreSQL authorization model: Transfer table ownership to the user, replacing p4_UID with the RAM user identifier:

      ALTER TABLE tablename OWNER TO "p4_UID";

    • SPM: Add the user to the developer user group or a higher-permission group. See Use the simple permission model.

    permission denied for table xxx when querying a cross-schema view

    SLPM is enabled, and SLPM doesn't support views that reference tables across schemas. Check whether you are creating a view across schemas in the SLPM.

    permission denied for Schema xxx

    The user lacks permissions on the schema. Fix this based on your permission model:

    • SPM or SLPM: Add the user to the appropriate user group:

      • For read access (queries): viewer user group or higher

      • For write access (table creation): developer user group or higher

    • Standard PostgreSQL authorization model: Grant schema permissions explicitly, replacing the placeholder with the Alibaba Cloud account or email:

      -- Grant USAGE to allow querying tables in the schema
GRANT USAGE ON SCHEMA <schema_name> TO "Alibaba Cloud account/email";
-- Grant CREATE to allow creating tables in the schema
GRANT CREATE ON SCHEMA <schema_name> TO "Alibaba Cloud account/email";

      After granting permissions, rerun the original query to confirm access.

    ALTER TABLE xxx is not supported in Simple Privilege Mode

    SPM is enabled, and SPM doesn't allow direct ALTER TABLE operations. Use one of these approaches: