Re: predefined role(s) for VACUUM and ANALYZE
Mark Dilger <mark.dilger@enterprisedb.com>
From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
"David G. Johnston" <david.g.johnston@gmail.com>,
Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
Robert Haas <robertmhaas@gmail.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-09-07T23:15:23Z
Lists: pgsql-hackers
> On Sep 7, 2022, at 4:09 PM, Stephen Frost <sfrost@snowman.net> wrote: > > Calling this a redesign is over-stating things, imv … and I’d much rather have the per-relation granularity than predefined roles for this, so there is that to consider too, perhaps. Ok, now I'm a bit lost. If I want to use Nathan's feature to create a role to vacuum and analyze my database on a regular basis, how does per-relation granularity help me? If somebody creates a new table and doesn't grant those privileges to the role, doesn't that break the usage case? To me, per-relation granularity sounds useful, but orthogonal, to this feature. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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