Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT.

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT.
Дата
Msg-id 20211103184607.GE20998@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT.  ("Bossart, Nathan" <bossartn@amazon.com>)
Список pgsql-hackers
Greetings,

* Bossart, Nathan (bossartn@amazon.com) wrote:
> On 11/2/21, 11:27 AM, "Stephen Frost" <sfrost@snowman.net> wrote:
> > * Bossart, Nathan (bossartn@amazon.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.

Yeah, that's exactly the thing I was thinking about that might seem odd.
I don't think it's a huge deal but I do think it'd be good for us to at
least think about if we're ok with that or if we want to try and do
something a bit better.

Thanks,

Stephen

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: XTS cipher mode for cluster file encryption
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Add option --drop-cascade for pg_dump/restore