Properly document that SIGTERM is OK for users to use on a postgres

session, now that pg_terminate_backend() uses it.

Josh Kupershmidt

diff --git a/doc/src/sgml/ref/postgres-ref.sgml b/doc/src/sgml/ref/postgres-ref.sgml
index 41745fb34dc22ece126957036b354ab157ae9ed8..943a3be00e37e5d367a539673e4a8b923800d1ac 100644 (file)
--- a/doc/src/sgml/ref/postgres-ref.sgml
+++ b/doc/src/sgml/ref/postgres-ref.sgml
@@ -732,14 +732,18 @@ PostgreSQL documentation
 
   
    To cancel a running query, send the SIGINT signal
-   to the process running that command.
+   to the process running that command. To terminate a backend process
+   cleanly, send SIGTERM to that process. See
+   also pg_cancel_backend and pg_terminate_backend
+   in  for the SQL-callable equivalents
+   of these two actions.
   
 
   
-   The postgres server uses SIGTERM
-   to tell subordinate server processes to quit normally and
-   SIGQUIT to terminate without the normal cleanup.
-   These signals should not be used by users.  It
+   The postgres server uses SIGQUIT
+   to tell subordinate server processes to terminate without normal
+   cleanup.
+   This signal should not be used by users.  It
    is also unwise to send SIGKILL to a server
    process — the main postgres process will
    interpret this as a crash and will force all the sibling processes