Horton

Re: predefined role(s) for VACUUM and ANALYZE

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Stephen Frost <sfrost@snowman.net>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, "David G. Johnston" <david.g.johnston@gmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-09-20T05:45:52Z
Lists: pgsql-hackers 
On Mon, Sep 19, 2022 at 08:51:47PM -0700, Nathan Bossart wrote:
> Are there any concerns with simply expanding AclMode to 64 bits, as done in
> v5 [0]?
> 
> [0] https://postgr.es/m/20220908055035.GA2100193%40nathanxps13

I have gone through the thread, and I'd agree with getting more
granularity when it comes to assigning ACLs to relations rather than
just an on/off switch for the objects of a given type would be nice.
I've been looking at the whole use of AclMode and AclItem in the code,
and I don't quite see why a larger size could have a noticeable
impact.  There are a few things that could handle a large number of
AclItems, though, say for array operations like aclupdate().  These
could be easily checked with some micro-benchmarking or some SQL
queries that emulate a large number of items in aclitem[] arrays.

Any impact for the column sizes of the catalogs holding ACL
information?  Just asking while browsing the patch set.

Some comments in utils/acl.h need a refresh as the number of lower and
upper bits looked at from ai_privs changes.
--
Michael

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