At Wed, 15 Apr 2020 15:58:05 +0500, "Andrey M. Borodin" <x4...@yandex-team.ru> wrote in > > 15 апр. 2020 г., в 15:25, Magnus Hagander <mag...@hagander.net> написал(а): > > I think that makes perfect sense. The documentation explicitly says "can > > read all pg_stat_* views", which is clearly wrong -- so either the code or > > the docs should be fixed, and it looks like it's the code that should be > > fixed to me. > Should it be bug or v14 feature? > > Also pgstatfuncs.c contains a lot more checks of > has_privs_of_role(GetUserId(), beentry->st_userid). > Maybe grant them all? > > > As for the patch, one could argue that we should just store the resulting > > boolean instead of re-running the check (e.g. have a "bool > > has_stats_privilege" or such), but perhaps that's an unnecessary > > micro-optimization, like the attached. > > Looks good to me.
pg_stat_get_activty checks (has_privs_of_role() || is_member_of_role()) in-place for every entry. It's not necessary but I suppose that doing the same thing for pg_stat_progress_info might be better. It's another issue, but pg_stat_get_backend_* functions don't consider pg_read_all_stats. I suppose that the functions should work under the same criteria to pg_stat views, and maybe explicitly documented? If we do that, it may be better that we define "PGSTAT_VIEW_PRIV()" or something like and replace the all occurances of the idiomatic condition with it. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
