From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT. |
Date: | 2021-10-26 20:02:55 |
Message-ID: | 20211026200255.GO20998@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
* Jeff Davis (pgsql(at)j-davis(dot)com) wrote:
> On Tue, 2021-10-26 at 00:07 +0000, Bossart, Nathan wrote:
> > It feels a bit excessive to introduce a new predefined role just for
> > this. Perhaps this could be accomplished with a new function that
> > could be granted.
>
> It would be nice if the syntax could be used, since it's pretty
> widespread. I guess it does feel excessive to have its own predefined
> role, but at the same time it's hard to group a command like CHECKPOINT
> into a category. Maybe if we named it something like pg_performance or
> something we could make a larger group?
For the use-case presented, I don't really buy off on this argument.
We're talking about benchmarking tools, surely they can be and likely
already are updated with some regularity for new major versions of PG.
I wonder also if there aren't other things besides this that would need
to be changed for them to work as a non-superuser anyway too, meaning
this would be just one change among others that they'd need to make.
In this specific case, I'd be more inclined to provide a function rather
than an explicit predefined role for this one thing.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Jonathan S. Katz | 2021-10-26 20:04:01 | Re: allowing "map" for password auth methods with clientcert=verify-full |
Previous Message | Stephen Frost | 2021-10-26 19:43:30 | Re: XTS cipher mode for cluster file encryption |