Обсуждение: Invalidate acl.c caches for pg_authid.rolinherit changes

Backends reflect "GRANT role_name" changes rather quickly, due to a syscache
invalidation callback.  Let's register an additional callback to reflect
"ALTER ROLE ... [NO]INHERIT" with equal speed.  I propose to back-patch this.
While pg_authid changes may be more frequent than pg_auth_members changes, I
expect neither is frequent enough to worry about the resulting acl.c cache
miss rate.

pg_authid changes don't affect cached_membership_roles, so I could have
invalidated cached_privs_roles only.  That felt like needless complexity.  I
expect cached_privs_role gets the bulk of traffic, since SELECT, INSERT,
UPDATE and DELETE use it.  cached_membership_roles pertains to DDL and such.

On 12/21/20, 1:51 AM, "Noah Misch" <noah@leadboat.com> wrote:
> Backends reflect "GRANT role_name" changes rather quickly, due to a syscache
> invalidation callback.  Let's register an additional callback to reflect
> "ALTER ROLE ... [NO]INHERIT" with equal speed.  I propose to back-patch this.
> While pg_authid changes may be more frequent than pg_auth_members changes, I
> expect neither is frequent enough to worry about the resulting acl.c cache
> miss rate.

+1 to back-patching.

> pg_authid changes don't affect cached_membership_roles, so I could have
> invalidated cached_privs_roles only.  That felt like needless complexity.  I
> expect cached_privs_role gets the bulk of traffic, since SELECT, INSERT,
> UPDATE and DELETE use it.  cached_membership_roles pertains to DDL and such.

The patch looks reasonable to me.

Nathan