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.