Hi

Currently the documentation for the default role "pg_signal_backend" states,
somewhat ambiguously, "Send signals to other backends (eg: cancel query, 
terminate)",
giving the impression other signals (e.g. SIGHUP) can be sent too, which is
currently not the case.

Attached patch clarifies this, adds a descriptive paragraph (similar to what
the other default roles have) and a link to the "Server Signaling Functions"
section.

Patch applies cleanly to HEAD and REL_11_STABLE.


Regards

Ian Barwick


--
 Ian Barwick                   https://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services
diff --git a/doc/src/sgml/user-manag.sgml b/doc/src/sgml/user-manag.sgml
new file mode 100644
index 6106244..76b6ddb
*** a/doc/src/sgml/user-manag.sgml
--- b/doc/src/sgml/user-manag.sgml
*************** DROP ROLE doomed_role;
*** 532,538 ****
        </row>
        <row>
         <entry>pg_signal_backend</entry>
!        <entry>Send signals to other backends (eg: cancel query, terminate).</entry>
        </row>
        <row>
         <entry>pg_read_server_files</entry>
--- 532,538 ----
        </row>
        <row>
         <entry>pg_signal_backend</entry>
!        <entry>Signal another backend to cancel a query or terminate the backend.</entry>
        </row>
        <row>
         <entry>pg_read_server_files</entry>
*************** DROP ROLE doomed_role;
*** 561,566 ****
--- 561,573 ----
     </table>
  
    <para>
+   The <literal>pg_signal_backend</literal> role is intended to allow administrators to enable
+   trusted, but non-superuser, roles to send signals to other backends. Currently this role
+   enables sending of signals for canceling a query on another backend or terminating the
+   backend. A user granted this role cannot however send signals to a backend owned by a superuser.
+   See also <xref linkend="functions-admin-signal"/>.
+   </para>
+   <para>
    The <literal>pg_read_server_files</literal>, <literal>pg_write_server_files</literal> and
    <literal>pg_execute_server_program</literal> roles are intended to allow administrators to have
    trusted, but non-superuser, roles which are able to access files and run programs on the

Reply via email to