Re: predefined role(s) for VACUUM and ANALYZE

Nathan Bossart <nathandbossart@gmail.com>

From: Nathan Bossart <nathandbossart@gmail.com>
To: Stephen Frost <sfrost@snowman.net>
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-28T20:12:22Z
Lists: pgsql-hackers
On Wed, Sep 28, 2022 at 03:09:46PM -0400, Stephen Frost wrote:
> On Wed, Sep 28, 2022 at 14:50 Nathan Bossart <nathandbossart@gmail.com>
> wrote:
>> 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.

While pg_class doesn't have a TOAST table, that column is marked as
"extended," so I believe it is still compressed, and the maximum aclitem
array length for pg_class.relacl would depend on how well the array
compresses.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



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