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      
PostgreSQL Development, 24x7 Support, Training & Services

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to