Text Size: Normal / Large

16.6. Shutting Down the Server

There are several ways to shut down the database server. You control the type of shutdown by sending different signals to the postmaster process.

SIGTERM

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 normally. This is the Smart Shutdown.

SIGINT

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 the server processes to exit and finally shuts down. This is the Fast Shutdown.

SIGQUIT

This is the Immediate Shutdown, which will cause the postmaster process to 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.

Important: It is best not to use SIGKILL to shut down the server. This will prevent the server from releasing shared memory and semaphores, which may then have to be done by manually.

The PID of the postmaster process can be found using the ps program, or from the file postmaster.pid in the data directory. So for example, to do a fast shutdown:

$ kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`

The program pg_ctl is a shell script that provides a more convenient interface for shutting down the server.


User Comments


Paul <nitrous AT fuckoff.com>
13 May 2006 4:14:58

SIGTERM: "disallows new connections, but lets existing sessions end their work normally"

SIGINT: "disallows new connections and sends all existing server processes SIGTERM, which will cause them to abort their current transactions and exit promptly"

How can SIGINT abort current transactions, if it sends SIGTERM to let existing sessions finish their work?

bah. My experience is that shutting down Postgres is a crapshoot. Sometimes sessions finish, sometimes they don't. Sometimes the DB is readable, sometimes it isn't. Keep backups.

Add Comment

Please use this form to add your own comments regarding your experience with particular features of PostgreSQL, clarifications of the documentation, or hints for other users. Please note, this is not a support forum, and your IP address will be logged. If you have a question or need help, please see the faq, try a mailing list, or join us on IRC. Note that submissions containing URLs or other keywords commonly found in 'spam' comments may be silently discarded. Please contact the webmaster if you think this is happening to you in error.

In order to submit a comment, you must have a community account.

* Comment
 

* denotes required field

Privacy Policy | Project hosted by hub.org | Designed by tinysofa
Copyright © 1996 – 2007 PostgreSQL Global Development Group