Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "alexwork033(at)gmail(dot)com" <alexwork033(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs
Date: 2024-03-27 19:46:57
Message-ID: CAEudQArfTcznjhNVH-T26640-4nRNQfAgouZEoVm=6fiKT0ZkQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em qua., 27 de mar. de 2024 às 14:35, Nathan Bossart <
nathandbossart(at)gmail(dot)com> escreveu:

> On Wed, Mar 27, 2024 at 01:47:38PM -0300, Ranier Vilela wrote:
> > Em qua., 27 de mar. de 2024 às 13:41, Nathan Bossart <
> > nathandbossart(at)gmail(dot)com> escreveu:
> >> On Wed, Mar 27, 2024 at 01:21:23PM -0300, Ranier Vilela wrote:
> >> > I think that left an oversight in a commit d365ae7
> >> > <
> >>
> https://github.com/postgres/postgres/commit/d365ae705409f5d9c81da4b668f59c3598feb512
> >> >
> >> > If the admin_role is a NULL pointer, so, can be dereferenced
> >> > in the main loop of the function roles_is_member_of and
> >> > worst, IMO, can be destroying aleatory memory?
> >> >
> >> > First, is a better shortcut test to check if admin_role is NOT NULL.
> >> > Second, !OidIsValid(*admin_role), It doesn't seem necessary anymore.
> >> >
> >> > Or am I losing something?
> >>
> >> If admin_role is NULL, then admin_of is expected to be set to
> InvalidOid.
> >> See the assertion at the top of the function. AFAICT the code that
> >> dereferences admin_role short-circuits if admin_of is invalid.
> >>
> > These conditions seem a little fragile and confusing to me.
> > When a simple test, it protects the pointer and avoids a series of tests,
> > which are unnecessary if the pointer is invalid.
>
> Maybe. But that doesn't seem like an oversight in commit d365ae7.
>
Sorry for exceeding.

>
> - if (otherid == admin_of && form->admin_option &&
> - OidIsValid(admin_of) &&
> !OidIsValid(*admin_role))
> + if (admin_role != NULL && otherid == admin_of &&
> form->admin_option &&
> + OidIsValid(admin_of))
> *admin_role = memberid;
>
> I'm not following why it's safe to remove the !OidIsValid(*admin_role)
> check here. We don't want to overwrite a previously-set value of
> *admin_role, as per the comment above roles_is_member_of():
>
> * If admin_of is not InvalidOid, this function sets *admin_role, either
> * to the OID of the first role in the result list that directly possesses
> * ADMIN OPTION on the role corresponding to admin_of, or to InvalidOid if
> * there is no such role.
>
Ok. If admin_role is NOT NULL, so *admin_role is InvalidOid, by
initialization
in the head of function.

I think that a cheap test *admin_role == InvalidOid, is enough?
What do you think?

v1 attached.

best regards,
Ranier Vilela

Attachment Content-Type Size
v1-avoid-dereference-a-null-pointer-acl.patch application/octet-stream 721 bytes

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2024-03-27 20:15:23 Re: Use streaming read API in ANALYZE
Previous Message Melanie Plageman 2024-03-27 19:37:50 Re: BitmapHeapScan streaming read user and prelim refactoring