Stephen Frost wrote:
> pgstat_get_backend_current_activity()
> Used to decide if the current activity string should be returned or
> not. In my view, this is a clear case which should be addressed
> through has_privs_of_role() instead of requiring the user to
> SET ROLE to each role they are an inheirited member of to query for
> what the other sessions are doing.
>
> pg_signal_backend()
> Used to decide if pg_terminate_backend and pg_cancel_backend are
> allowed. Another case which should be changed over to
> has_privs_of_role(), in my view. Requiring the user to SET ROLE for
> roles which they are an inheirited member of is confusing as it's
> generally not required.
>
> pg_stat_get_activity()
> Used to decide if the state information should be shared.
> My opinion is the same as above- use has_privs_of_role().
> There are a number of other functions in pgstatfuncs.c with similar
> issues (eg: pg_stat_get_backend_activity(),
> pg_stat_get_backend_client_port(), and others).
I think the case for pgstat_get_backend_current_activity() and
pg_stat_get_activity and the other pgstatfuncs.c callers is easy to make
and seems acceptable to me; but I would leave pg_signal_backend out of
that discussion, because it has a potentially harmful side effect. By
requiring SET ROLE you add an extra layer of protection against
mistakes. (Hopefully, pg_signal_backend() is not a routine thing for
well-run systems, which means human intervention, and therefore the room
for error isn't insignificant.)
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
