- linkend="sysvipc-parameters">. The parameter SEMMNI>
+ linkend="sysvipc-parameters">). The parameter SEMMNI>
determines the limit on the number of semaphore sets that can
exist on the system at one time. Hence this parameter must be at
least ceil(max_connections / 16)>. Lowering the number
#define SHMALL /* max amount of shared memory (pages) */
- To increase the number of buffers supported by the postmaseter, add the
+ To increase the number of buffers supported by the postmaster, add the
following to your kernel config file. A SHMALL> value of 1024
represents 4MB of shared memory. Increase it accordingly:
Semaphores>
You may need to increase the number of semaphores. By
- default,
Postgres> allocates 32 semaphores,
- one for each backend connection. This is just over half the
- default system total of 60.
+ default,
Postgres> allocates 34 semaphores,
+ which is over half the default system total of 60.
counts but it can be changed by the user up to the hard limit.
The hard limit can only be changed by the root user. The system
call setrlimit is responsible for setting
- these parameters. The shell the built-in command
+ these parameters. The shell's built-in command
ulimit (Bourne shells) or
limit (csh) is used to control the resource
limits from the command line. On BSD-derived systems the file
After receiving SIGTERM, the postmaster disallows new
- connections but lets active backend end their work and shuts
- down only after all of them terminated (by client request).
+ connections, but lets existing backends end their work normally.
+ It shuts down only after all of the backends terminate by client
+ request.
This is the Smart Shutdown.
SIGINT
- The postmaster disallows new connections, sends all active
- backends SIGTERM (which will cause them to abort immediately),
- waits for children to exit and shuts down the data base. This
- is the Fast Shutdown.
+ The postmaster disallows new connections and sends all existing
+ backends SIGTERM, which will cause them to abort their current
+ transactions and exit promptly. It then waits for the backends to exit
+ and finally shuts down the data base.
+ This is the Fast Shutdown.
This is the Immediate Shutdown which
will cause the postmaster to send a SIGQUIT to all backends and
exit immediately (without properly shutting down the database
- system). When WAL is implemented, this will lead to recovery on
- start-up. Right now it's not recommendable to use this option.
+ system). The backends 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.
- If at all possible, do not use SIGKILL to shut down the
- postmaster. This can cause data corruption and will prevent the
- cleaning up of shared memory resources, which you will have to
- do yourself in that case.
+ It is best not to use SIGKILL to shut down the postmaster. This
+ will prevent the postmaster from releasing shared memory and
+ semaphores, which you may then have to do by hand.
postmaster.pid in the data directory. So for
example, to do a fast shutdown:
-> kill -INT `cat /usr/local/pgsql/data/postmaster.pid`
+> kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`
The program
pg_ctl is a shell script
- wrapper that provides a convenient interface to these functions.
+ that provides a more convenient interface for shutting down the
+ postmaster.