Horton

Re: predefined role(s) for VACUUM and ANALYZE

David G. Johnston <david.g.johnston@gmail.com>

View thread View on postgr.es
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Nathan Bossart <nathandbossart@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-07-26T17:50:32Z
Lists: pgsql-hackers 
On Tue, Jul 26, 2022 at 10:37 AM Robert Haas <robertmhaas@gmail.com> wrote:

> On Mon, Jul 25, 2022 at 9:47 PM Kyotaro Horiguchi
> <horikyota.ntt@gmail.com> wrote:
> > One arguable point would be whether we will need to put restriction
> > the target relations that Bob can vacuum/analyze.
>


> But for a command with a target, you really ought to have a
> permission on the object, not just a general permission. On the other
> hand, we do have things like pg_read_all_tables, so we could have
> pg_vacuum_all_tables too.


I'm still more likely to create a specific security definer function owned
by the relevant table owner to give out ANALYZE (and maybe VACUUM)
permission to ETL-performing roles.

Still, it seems somewhat appealing to give
> people fine-grained control over this, rather than just "on" or "off".
>
>
Appealing enough to consume a couple of permission bits?

https://www.postgresql.org/message-id/CAKFQuwZ6dhjTFV7Bwmehe1N3%3Dk484y4mM22zuYjVEU2dq9V1aQ%40mail.gmail.com

David J.

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