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
-
Provide non-superuser predefined roles for vacuum and analyze
- 4441fc704d70 16.0 landed
-
Provide per-table permissions for vacuum and analyze.
- b5d6382496f2 16.0 landed
-
Expand AclMode to 64 bits
- 7b378237aa80 16.0 landed
-
Simplify WARNING messages from skipped vacuum/analyze on a table
- b7a5ef17cf75 16.0 landed
-
Allow granting SET and ALTER SYSTEM privileges on GUC parameters.
- a0ffa885e478 15.0 cited
-
Add String object access hooks
- d11e84ea466b 15.0 cited