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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
