Let mdb_admin manage resource groups#1804
Open
Alena0704 wants to merge 1 commit into
Open
Conversation
my-ship-it
reviewed
Jun 4, 2026
my-ship-it
reviewed
Jun 4, 2026
| rolcreaterole => 'f', rolcreatedb => 'f', rolcanlogin => 'f', | ||
| rolreplication => 'f', rolbypassrls => 'f', rolconnlimit => '-1', | ||
| rolpassword => '_null_', rolvaliduntil => '_null_' }, | ||
| { oid => '6312', oid_symbol => 'ROLE_PG_MANAGE_RESOURCE_GROUPS', |
Contributor
There was a problem hiding this comment.
Can ROLE_PG_MANAGE_RESOURCE_GROUPS be dropped? If dropped, we cannot create it again.
Contributor
Author
There was a problem hiding this comment.
We can't drop this role. This function checks it:
/* This case can be dispatched quickly */
if (IsPinnedObject(classId, objectId))
{
object.classId = classId;
object.objectId = objectId;
object.objectSubId = 0;
ereport(ERROR,
(errcode(ERRCODE_DEPENDENT_OBJECTS_STILL_EXIST),
errmsg("cannot drop %s because it is required by the database system",
getObjectDescription(&object, false))));
}
src/backend/catalog/pg_shdepend.c:654
my-ship-it
reviewed
Jun 4, 2026
| rolreplication => 'f', rolbypassrls => 'f', rolconnlimit => '-1', | ||
| rolpassword => '_null_', rolvaliduntil => '_null_' }, | ||
| { oid => '6312', oid_symbol => 'ROLE_PG_MANAGE_RESOURCE_GROUPS', | ||
| rolname => 'pg_manage_resource_groups', rolsuper => 'f', rolinherit => 't', |
Contributor
There was a problem hiding this comment.
We change catalog here, but for 2X_STABLE, we suppose not.
Contributor
Author
Contributor
my-ship-it
reviewed
Jun 4, 2026
|
|
||
| /* The system admin_group can only be altered by a superuser. */ | ||
| if (!superuser() && (strcmp(stmt->name, "admin_group") == 0)) | ||
| ereport(ERROR, |
Contributor
There was a problem hiding this comment.
Should we also protect SYSTEMRESGROUP_OID?
Contributor
Author
There was a problem hiding this comment.
I think we should compare it with admin_group and default_group too. because the first one is a default group for superuser sessions and default_group contains system roles without superuser privileges.
Alena0704
force-pushed
the
REL_2_STABLE-mdb_admin-resource-group
branch
from
3cf18f1 to
c429871
Compare
Contributor
Author
|
I rewrote the patch completely because a new bootstrap catalog entry bumps CATALOG_VERSION_NO and incompatible with minor gpupgrade - I adapted the commit from open-gpdb 3ac99962ad2 and added my tests. |
Alena0704
changed the title
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 apache#1763.
Alena0704
force-pushed
the
REL_2_STABLE-mdb_admin-resource-group
branch
from
c429871 to
d2ba7c6
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Let mdb_admin manage resource groups
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:
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.
Fixes #ISSUE_Number
What does this PR do?
Type of Change
Breaking Changes
Test Plan
make installcheckmake -C src/test installcheck-cbdb-parallelImpact
Performance:
User-facing changes:
Dependencies:
Checklist
Additional Context
CI Skip Instructions