There are several ways to shut down the database server. You
control the type of shutdown by sending different signals to the
This is the Smart Shutdown mode. After receiving SIGTERM, the server disallows new connections, but lets existing sessions end their work normally. It shuts down only after all of the sessions terminate. If the server is in online backup mode, it additionally waits until online backup mode is no longer active. While backup mode is active, new connections will still be allowed, but only to superusers (this exception allows a superuser to connect to terminate online backup mode). If the server is in recovery when a smart shutdown is requested, recovery and streaming replication will be stopped only after all regular sessions have terminated.
This is the Fast Shutdown mode. The server disallows new connections and sends all existing server processes SIGTERM, which will cause them to abort their current transactions and exit promptly. It then waits for all server processes to exit and finally shuts down. If the server is in online backup mode, backup mode will be terminated, rendering the backup useless.
This is the Immediate Shutdown mode. The server will send SIGQUIT to all child processes and wait for them to terminate. If any do not terminate within 5 seconds, they will be sent SIGKILL. The master server process exits as soon as all child processes have exited, without doing normal database shutdown processing. This will lead to recovery (by replaying the WAL log) upon next start-up. This is recommended only in emergencies.
The pg_ctl program provides a
convenient interface for sending these signals to shut down the
server. Alternatively, you can send the signal directly using
kill on non-Windows systems. The
PID of the
postgres process can be found using the
ps program, or from the file
postmaster.pid in the data
directory. For example, to do a fast shutdown:
kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`
It is best not to use SIGKILL to shut down the server. Doing so
will prevent the server from releasing shared memory and
semaphores, which might then have to be done manually before a
new server can be started. Furthermore, SIGKILL kills the
postgres process without letting it relay the
signal to its subprocesses, so it will be necessary to kill the
individual subprocesses by hand as well.
To terminate an individual session while allowing other
sessions to continue, use
pg_terminate_backend() (see Table 9.78)
or send a SIGTERM signal to the
child process associated with the session.
If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.