risingwavelabs/risingwave · error · anyhow::Error

PostgreSQL table {} exists, but the connection user `{}` doe

Error message

PostgreSQL table {} exists, but the connection user `{}` does not have {} privilege on it.{} Grant privileges on the upstream PostgreSQL database: {}

What it means

When setting up PostgreSQL CDC, RisingWave checks that the connection user holds table-level privileges (e.g. SELECT) on the source table. This error is thrown by `ensure_table_privilege` when the table exists but the user lacks the required table-level privilege, and it appends a note when the user only has column-level privileges, since CDC schema discovery and snapshot reads need full table access.

Source

Thrown at src/connector/src/connector_common/postgres.rs:363

        if !privilege_status.has_schema_usage {
            return Err(anyhow!(
                "PostgreSQL table {} exists, but the connection user `{}` does not have USAGE privilege on schema `{}`. Grant privileges on the upstream PostgreSQL database: {}",
                format_pg_table_name(schema, table),
                privilege_status.user_name,
                schema,
                format_grant_usage(schema, &privilege_status.user_name),
            )
            .into());
        }

        if !privilege_status.has_table_privilege {
            let column_privilege_msg = if privilege_status.has_any_column_privilege {
                " The user has column-level privilege on at least one column, but RisingWave requires table-level privilege for CDC schema discovery and snapshot reads."
            } else {
                ""
            };
            return Err(anyhow!(
                "PostgreSQL table {} exists, but the connection user `{}` does not have {} privilege on it.{} Grant privileges on the upstream PostgreSQL database: {}",
                format_pg_table_name(schema, table),
                privilege_status.user_name,
                required_privilege,
                column_privilege_msg,
                format_required_table_grants(
                    schema,
                    table,
                    &privilege_status.user_name,
                    required_privilege
                ),
            )
            .into());
        }

        Ok(())
    }

View on GitHub (pinned to 6469eb736d)

Solutions

1. Run `GRANT SELECT ON <schema>.<table> TO <user>;` as superuser on the upstream PostgreSQL database
2. Verify current privileges with `SELECT * FROM information_schema.role_table_grants WHERE grantee = '<user>';`
3. If column-level grants were intended, replace them with table-level grants: `REVOKE SELECT(...) ON ...; GRANT SELECT ON ...;`
4. Re-run the RisingWave CDC table creation after granting

Example fix

-- before (column-level only)
GRANT SELECT (id, payload) ON public.orders TO rw_user;
-- after
GRANT SELECT ON public.orders TO rw_user;

-- run as superuser before creating the RW CDC table
SELECT has_table_privilege('rw_user', 'public.orders', 'SELECT') AS table_ok;
-- if false, fix with:
GRANT SELECT ON public.orders TO rw_user;

match ensure_table_privilege_result {
    Err(e) if e.to_string().contains("does not have") => {
        // surface remediation SQL to the DBA before retrying
        return Err(GuidanceError::new(e, "GRANT SELECT ON <table> TO <user>;"));
    }
    r => r,
}

When it happens

Trigger: Calling the CDC table creation path (`ensure_table_privilege` during connector setup) where a privilege query reports `has_table_privilege == false` for the configured table, schema, and connection user.

Common situations: The DBA granted only column-level SELECT on some columns; the user was granted privileges on other tables in the schema but not this one; the role was created after table creation without default privileges; connecting via a limited service account.

Understand the failure class

Background: Permission denied / not authorized / 403 Forbidden: access-control rejections when the caller lacks the required role, grant, or ownership — this error's family across 18 libraries.

Related errors

• PostgreSQL table {} exists, but the connection user `{}` doe
• Postgres table should define the primary key for non-append-
• {:?} data type is not supported
• failed to convert PostgreSQL snapshot column `{name}` to {da
• PostgreSQL snapshot column `{name}` vector dimension mismatc

AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11). Data as JSON: /api/errors/83454654a0952407. Report an issue: GitHub.