Horton

Re: predefined role(s) for VACUUM and ANALYZE

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: 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>, Michael Paquier <michael@paquier.xyz>, Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-09-30T20:15:24Z
Lists: pgsql-hackers 
Nathan Bossart <nathandbossart@gmail.com> writes:
> Are there any remaining concerns about this approach?  I'm happy to do any
> testing that folks deem necessary, or anything else really that might help
> move this patch set forward.  If we don't want to extend AclMode right
> away, we could also keep it in our back pocket for the next time someone
> (which may very well be me) wants to add privileges.  That is, 0001 is not
> fundamentally a prerequisite for 0002-0004, but I recognize that freeing up
> some extra bits would be the most courteous.

In view of the recent mess around bigint relfilenodes, it seems to me
that we shouldn't move forward with widening AclMode unless somebody
runs down which structs will get wider (or more aligned) and how much
that'll cost us.  Maybe it's not a problem, but it could do with an
explicit look at the point.

I do agree with the position that these features are not where to
spend our last remaining privilege bits.

			regards, tom lane

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