Before anyone can access the database, you must start the
database server. The database server program is called postgres. The postgres
program must know where to find the data it is supposed to use.
This is done with the -D option. Thus,
the simplest way to start the server is:

$ postgres -D /usr/local/pgsql/data

which will leave the server running in the foreground. This
must be done while logged into the PostgreSQL user account. Without -D, the server will try to use the data directory
named by the environment variable PGDATA.
If that variable is not provided either, it will fail.

Normally it is better to start postgres in the background. For this, use the
usual Unix shell syntax:

$ postgres -D /usr/local/pgsql/data >logfile 2>&1 &

It is important to store the server's stdout and stderr output somewhere, as shown above. It
will help for auditing purposes and to diagnose problems. (See
Section 23.3 for a more
thorough discussion of log file handling.)

The postgres program also takes a
number of other command-line options. For more information, see
the postgres reference page and Chapter 18 below.

This shell syntax can get tedious quickly. Therefore the
wrapper program pg_ctl is provided to simplify some
tasks. For example:

pg_ctl start -l logfile

will start the server in the background and put the output
into the named log file. The -D option
has the same meaning here as for postgres. pg_ctl is also
capable of stopping the server.

Normally, you will want to start the database server when the
computer boots. Autostart scripts are operating-system-specific.
There are a few distributed with PostgreSQL in the contrib/start-scripts directory. Installing one
will require root privileges.

Different systems have different conventions for starting up
daemons at boot time. Many systems have a file /etc/rc.local or /etc/rc.d/rc.local. Others use init.d or rc.d
directories. Whatever you do, the server must be run by the
PostgreSQL user account
and not by root or any
other user. Therefore you probably should form your commands
using su postgres -c '...'. For
example:

su postgres -c 'pg_ctl start -D /usr/local/pgsql/data -l serverlog'

Here are a few more operating-system-specific suggestions. (In
each case be sure to use the proper installation directory and
user name where we show generic values.)

For FreeBSD, look at the
file contrib/start-scripts/freebsd
in the PostgreSQL source
distribution.

While the server is running, its PID is stored in the file postmaster.pid in the data directory. This is
used to prevent multiple server instances from running in the
same data directory and can also be used for shutting down the
server.

There are several common reasons the server might fail to
start. Check the server's log file, or start it by hand
(without redirecting standard output or standard error) and see
what error messages appear. Below we explain some of the most
common error messages in more detail.

LOG: could not bind IPv4 socket: Address already in use
HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
FATAL: could not create TCP/IP listen socket

This usually means just what it suggests: you tried to start
another server on the same port where one is already running.
However, if the kernel error message is not Address already in use or some variant
of that, there might be a different problem. For example,
trying to start a server on a reserved port number might draw
something like:

$ postgres -p 666
LOG: could not bind IPv4 socket: Permission denied
HINT: Is another postmaster already running on port 666? If not, wait a few seconds and retry.
FATAL: could not create TCP/IP listen socket

probably means your kernel's limit on the size of shared
memory is smaller than the work area PostgreSQL is trying to create (4011376640
bytes in this example). Or it could mean that you do not have
System-V-style shared memory support configured into your
kernel at all. As a temporary workaround, you can try starting
the server with a smaller-than-normal number of buffers
(shared_buffers).
You will eventually want to reconfigure your kernel to increase
the allowed shared memory size. You might also see this message
when trying to start multiple servers on the same machine, if
their total space requested exceeds the kernel limit.

An error like:

FATAL: could not create semaphores: No space left on device
DETAIL: Failed system call was semget(5440126, 17, 03600).

does not mean
you've run out of disk space. It means your kernel's limit on
the number of System V
semaphores is smaller than the number PostgreSQL wants to create. As above, you
might be able to work around the problem by starting the server
with a reduced number of allowed connections (max_connections),
but you'll eventually want to increase the kernel limit.

If you get an "illegal system
call" error, it is likely that shared memory or
semaphores are not supported in your kernel at all. In that
case your only option is to reconfigure the kernel to enable
these features.

Details about configuring System
VIPC facilities are
given in Section
17.4.1.

Although the error conditions possible on the client side
are quite varied and application-dependent, a few of them might
be directly related to how the server was started. Conditions
other than those shown below should be documented with the
respective client application.

psql: could not connect to server: Connection refused
Is the server running on host "server.joe.com" and accepting
TCP/IP connections on port 5432?

This is the generic "I couldn't find a
server to talk to" failure. It looks like the above when
TCP/IP communication is attempted. A common mistake is to
forget to configure the server to allow TCP/IP connections.

Alternatively, you'll get this when attempting Unix-domain
socket communication to a local server:

psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?

The last line is useful in verifying that the client is
trying to connect to the right place. If there is in fact no
server running there, the kernel error message will typically
be either Connection
refused or No such file or
directory, as illustrated. (It is important to realize
that Connection refused in
this context does not
mean that the server got your connection request and rejected
it. That case will produce a different message, as shown in
Section
19.4.) Other error messages such as Connection timed out might indicate
more fundamental problems, like lack of network
connectivity.

Submit correction

If you see anything in the documentation that is not correct, does not match
your experience with the particular feature or requires further clarification,
please use
this form
to report a documentation issue.