From 689015748f8dd7267355eb6b7088684183fc1159 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Thu, 18 Sep 2003 20:30:15 +0000 Subject: Put a tad more detail in the discussion of postmaster and postgres signal handling. --- doc/src/sgml/ref/postgres-ref.sgml | 28 ++++++++++++++++++++++------ 1 file changed, 22 insertions(+), 6 deletions(-) (limited to 'doc/src/sgml/ref/postgres-ref.sgml') diff --git a/doc/src/sgml/ref/postgres-ref.sgml b/doc/src/sgml/ref/postgres-ref.sgml index 9c961492a9e..b80c9caafac 100644 --- a/doc/src/sgml/ref/postgres-ref.sgml +++ b/doc/src/sgml/ref/postgres-ref.sgml @@ -1,5 +1,5 @@ @@ -365,13 +365,29 @@ PostgreSQL documentation Notes - To stop a running query use the SIGINT signal. To - tell postgres to reread the configuration file, - use a SIGHUP signal. The - postmaster uses SIGTERM + To cancel a running query, send the SIGINT signal + to the postgres process running that command. + + + + To tell postgres to reread the configuration file, + send a SIGHUP signal. Normally it's best to + SIGHUP the postmaster instead; + the postmaster will in turn SIGHUP + each of its children. But in some cases it might be desirable to have only + one postgres process reread the configuration file. + + + + The postmaster uses SIGTERM to tell a postgres process to quit normally and SIGQUIT to terminate without the normal cleanup. - These should not be used by users. + These signals should not be used by users. It is also + unwise to send SIGKILL to a postgres + process --- the postmaster will interpret this as + a crash in postgres, and will force all the sibling + postgres processes to quit as part of its standard + crash-recovery procedure. -- cgit v1.2.3