From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net>, Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Subject: | Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT. |
Date: | 2021-11-02 21:06:58 |
Message-ID: | 29D7022B-365A-4FE4-BA57-E48B73AC20AF@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/2/21, 11:27 AM, "Stephen Frost" <sfrost(at)snowman(dot)net> wrote:
> * Bossart, Nathan (bossartn(at)amazon(dot)com) wrote:
>> The approach in the patch looks alright to me, but another one could
>> be to build a SelectStmt when parsing CHECKPOINT. I think that'd
>> simplify the standard_ProcessUtility() changes.
>
> For my 2c, at least, I'm not really partial to either approach, though
> I'd want to see what error messages end up looking like. Seems like we
> might want to exercise a bit more control than we'd be able to if we
> transformed it directly into a SelectStmt (that is, we might add a HINT:
> roles with execute rights on pg_checkpoint() can run this command, or
> something; maybe not too tho).
I don't feel strongly one way or the other as well, but you have a
good point about extra control over the error messages. The latest
patch just does a standard aclcheck_error(), so you'd probably see
"permission denied for function" if you didn't have privileges for
CHECKPOINT. That could be confusing.
Nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Vik Fearing | 2021-11-02 21:35:34 | Re: should we enable log_checkpoints out of the box? |
Previous Message | Bossart, Nathan | 2021-11-02 20:57:58 | Re: archive modules |