Note: Contributed by Massimo Dal Zotto
Postgres uses the following signals for communication between the postmaster and backends:
Table 30-1. Postgres Signals
| Signal | postmaster Action | Server Action |
|---|---|---|
| SIGHUP | kill(*,sighup) | read_pg_options |
| SIGINT | die | cancel query |
| SIGQUIT | kill(*,sigterm) | handle_warn |
| SIGTERM | kill(*,sigterm), kill(*,9), die | die |
| SIGPIPE | ignored | die |
| SIGUSR1 | kill(*,sigusr1), die | quickdie |
| SIGUSR2 | kill(*,sigusr2) | async notify (SI flush) |
| SIGCHLD | reaper | ignored (alive test) |
| SIGTTIN | ignored | |
| SIGTTOU | ignored | |
| SIGCONT | dumpstatus | |
| 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