Server Control - PostgreSQL 9 Administration - page 71

UBUNTU/DEBIAN pg_ctlcluster 9.0 main reload

RED HAT/FEDORA service postgresql reload

pg_ctl -D /var/lib/pgsql/data reload

SOLARIS pg_ctl -D /var/lib/pgsql/data reload

MAC OS pg_ctl -D /var/lib/pgsql/data reload

FREEBSD pg_ctl -D /var/lib/pgsql/data reload

You can also reload the configuration files while still connected to PostgreSQL. This can be
done from the command line as follows, if you are a superuser:

postgres=# select pg_reload_conf();
pg_reload_conf
----------------
t

which is also often executed from an admin tool, such as pgAdmin3

If you do this, you should realize that it's possible to implement a new authentication rule
that is violated by the current session. It won't force you to disconnect, but when you do
disconnect, you may not be able to reconnect.

How it works...

To reload the configuration files, we send the SIGHUP signal to the postmaster, which then
passes that on to all connected backends. That's why some people call reloading the server
"sigh-up-ing".

If you look at the catalog table pg_settings , you'll see that there is a column named
context . Each setting has a time and a place where it can be changed. Some parameters
can only be reset by a server reload, and so the value of context for those parameters will be a
"sighup". Here are a few of the ones you'll want to change sometimes during server operation
(there are others!):

postgres=# SELECT name, setting, unit

,(source = 'default') as is_default

FROM pg_settings

WHERE context = 'sighup'

AND (name like '%delay' or name like '%timeout')

AND setting != '0';