Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT.
От | Stephen Frost |
---|---|
Тема | Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT. |
Дата | |
Msg-id | 20211108174723.GI20998@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT. (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT.
|
Список | pgsql-hackers |
Greetings, * Andres Freund (andres@anarazel.de) wrote: > On 2021-11-08 12:23:18 -0500, Stephen Frost wrote: > > though I continue to feel like the function based approach is better. > > I think it's a somewhat ugly hack. I suppose we'll just have to disagree on that. :) I don't feel as strongly as others apparently do on this point though, and I'd rather have non-superusers able to run CHECKPOINT *somehow* than not, so if the others feel like a predefined role is a better approach then I'm alright with that. Seems a bit overkill to me but it's also not like it's actually all that much code or work to do. > > then we must use such an approach no matter how we allow non-superusers to > > run the command because any approach to that necessarily involves some > > amount of catalog access. > > As long as there's no additional catalog access when the user is known to be a > superuser, then I think it's fine. There's a difference between doing one > pg_authid read for superuser - with a fallback to automatically assuming a > user if one couldn't be found - and doing a full pg_proc read with several > subsidiary pg_type reads etc. Yes, the approach I'm suggesting would make the superuser-run CHECKPOINT be exactly the same as it is today, while a non-superuser trying to run a CHECKPOINT would end up doing additional catalog accesses. Thanks, Stephen
Вложения
В списке pgsql-hackers по дате отправления: