There are several ways to shut down the database server. You control
the type of shutdown by sending different signals to the master
postgres process.
- SIGTERM
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.
- SIGINT
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.
- SIGQUIT
This is the Immediate Shutdown mode.
The master postgres process will send a
SIGQUIT to all child processes and exit
immediately, without properly shutting itself down. The child processes
likewise exit immediately upon receiving
SIGQUIT. 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`
Important: 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-56) or send a
SIGTERM signal to the child process associated with
the session.