You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Greenplum/Cloudberry only a superuser may CREATE/ALTER/DROP resource
groups. In managed-service deployments superuser is never handed to
the client, so a cloud admin has no way to tune their own CPU/memory
limits.
The upstream-shaped fix is a predefined role pinned in pg_authid.dat.
That is correct for master, but a new bootstrap catalog entry bumps
CATALOG_VERSION_NO and thus needs a fresh initdb / gpupgrade.
We must be able to grant this capability between minor versions.
So instead of pinning an OID, gate the four entry points on membership
of the mdb_admin role, resolved by name at runtime:
role = get_role_oid("mdb_admin", true);
if (!is_member_of_role(GetUserId(), role))
ereport(ERROR, (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE), ...));
mdb_admin is an ordinary role created by the control plane with a plain
CREATE ROLE, not a built-in catalog role. If the role does not exist,
get_role_oid returns InvalidOid, so on a stock cluster only superusers
pass the check and nothing changes. The capability is enabled only
where the control plane creates the role.
admin_group stays superuser-only for ALTER/DROP: it is infrastructure,
not a user-tunable group.
This commit is adapted from open-gpdb/gpdb commit 3ac99962ad2.
Some tests are added from apache/cloudberry PR #1763.
0 commit comments