Horton

Re: predefined role(s) for VACUUM and ANALYZE

Stephen Frost <sfrost@snowman.net>

View thread View on postgr.es
From: Stephen Frost <sfrost@snowman.net>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, "David G. Johnston" <david.g.johnston@gmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Michael Paquier <michael@paquier.xyz>, Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-09-28T19:09:46Z
Lists: pgsql-hackers 
Greetings,

On Wed, Sep 28, 2022 at 14:50 Nathan Bossart <nathandbossart@gmail.com>
wrote:

> On Tue, Sep 20, 2022 at 09:31:26PM -0700, Nathan Bossart wrote:
> > I bet a more pressing concern is the calls to aclmask() since checking
> > privileges is probably done more frequently than updating them.  That
> > appears to use a linear search, too, so maybe sorting the aclitem arrays
> is
> > actually worth exploring.  I still doubt there will be much noticeable
> > impact from expanding AclMode outside of the most extreme cases.
>
> I've been testing aclmask() with long aclitem arrays (2,000 entries is
> close to the limit for pg_class entries), and I haven't found any
> significant impact from bumping AclMode to 64 bits.


The max is the same regardless of the size..?  Considering the size is
capped since pg_class doesn’t (and isn’t likely to..) have a toast table,
that seems unlikely, so I’m asking for clarification on that. We may be
able to get consensus that the difference isn’t material since no one is
likely to have such long lists, but we should at least be aware.

Thanks,

Stephen

>

Commits

  1. Provide non-superuser predefined roles for vacuum and analyze

  2. Provide per-table permissions for vacuum and analyze.

  3. Expand AclMode to 64 bits

  4. Simplify WARNING messages from skipped vacuum/analyze on a table

  5. Allow granting SET and ALTER SYSTEM privileges on GUC parameters.

  6. Add String object access hooks