Horton

Thread

Commits

  1. Fix back-patch of "Invalidate acl.c caches when pg_authid changes."

  2. Invalidate acl.c caches when pg_authid changes.

  1. Invalidate acl.c caches for pg_authid.rolinherit changes

    Noah Misch <noah@leadboat.com> — 2020-12-21T09:50:28Z

    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.

  2. Re: Invalidate acl.c caches for pg_authid.rolinherit changes

    Nathan Bossart <bossartn@amazon.com> — 2020-12-21T19:01:51Z

    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