win -:|:- koi -:|:- iso -:|:- dos -:|:- mac

Start -:|:- Проекты -:|:- О нас

Chapter 54. Postgres Signals

Note: Contributed by Massimo Dal Zotto

Postgres uses the following signals for communication between the postmaster and backends:

Table 54-1. Postgres Signals

Signalpostmaster ActionServer Action
SIGINTdiecancel query
SIGTERMkill(*,sigterm), kill(*,9), diedie
SIGUSR1kill(*,sigusr1), diequickdie
SIGUSR2kill(*,sigusr2)async notify (SI flush)
SIGCHLDreaperignored (alive test)
SIGFPE FloatExceptionHandler

Note: "kill(*,signal)" means sending a signal to all backends.

The main changes to the old signal handling are the use of SIGQUIT instead of SIGHUP to handle warns, SIGHUP to re-read the pg_options file and the redirection to all active backends of SIGHUP, SIGTERM, SIGUSR1 and SIGUSR2 sent to the postmaster. In this way these signals sent to the postmaster can be sent automatically to all the backends without need to know their pids. To shut down postgres one needs only to send a SIGTERM to postmaster and it will stop automatically all the backends.

The SIGUSR2 signal is also used to prevent SI cache table overflow which happens when some backend doesn't process SI cache for a long period. When a backend detects the SI table full at 70% it simply sends a signal to the postmaster which will wake up all idle backends and make them flush the cache.

The typical use of signals by programmers could be the following:

# stop postgres
kill -TERM $postmaster_pid
# kill all the backends
kill -QUIT $postmaster_pid
# kill only the postmaster
kill -INT $postmaster_pid
# change pg_options
cat new_pg_options > $DATA_DIR/pg_options
kill -HUP $postmaster_pid
# change pg_options only for a backend
cat new_pg_options > $DATA_DIR/pg_options
kill -HUP $backend_pid
cat old_pg_options > $DATA_DIR/pg_options