Before anyone can access the database, you must start the database
server. The database server program is called
edb-postmaster.
The edb-postmaster 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:
$ edb-postmaster -D /opt/EnterpriseDB/8.2.1.2/data
which will leave the server running in the foreground. This must be
done while logged into the EnterpriseDB 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 the edb-postmaster in the
background. For this, use the usual shell syntax:
$ edb-postmaster -D /opt/EnterpriseDB/8.2.1.2/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 35.3 for a more thorough discussion of log
file handling.)
The edb-postmaster also takes a number of other
command line options. For more information, see the reference page
and Section 30.4 below.
This shell syntax can get tedious quickly. Therefore the shell
script wrapper
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 in the edb-postmaster. 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
EnterpriseDB 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
rc.d directories. Whatever you do, the server must be
run by the EnterpriseDB user account
and not by root or any other user. Therefore you
probably should form your commands using su -c '...'
enterprisedb. For example:
su -c 'pg_ctl start -D /opt/EnterpriseDB/8.2.1.2/data -l serverlog' enterprisedb
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
EnterpriseDB source distribution.
On OpenBSD, add the following lines
to the file /etc/rc.local:
if [ -x /usr/local/pgsql/bin/pg_ctl -a -x /usr/local/pgsql/bin/edb-postmaster ]; then
su - -c '/usr/local/pgsql/bin/pg_ctl start -l /var/postgresql/log -s' enterprisedb
echo -n ' postgresql'
fi
On Linux systems either add
/opt/EnterpriseDB/8.2.1.2//bin/pg_ctl start -l logfile -D /opt/EnterpriseDB/8.2.1.2/data
to /etc/rc.d/rc.local or look at the file
contrib/start-scripts/linux in the
EnterpriseDB source distribution.
On NetBSD, either use the
FreeBSD or
Linux start scripts, depending on
preference.
On Solaris, create a file called
/etc/init.d/postgresql that contains
the following line:
su - enterprisedb -c "/opt/EnterpriseDB/8.2.1.2//bin/pg_ctl start -l logfile
-D /opt/EnterpriseDB/8.2.1.2/data"
Then, create a symbolic link to it in /etc/rc3.d as
S99enterprisedb.
While the edb-postmaster is running, its
PID is stored in the file
edb-postmaster.pid in the data directory. This is
used to prevent multiple edb-postmaster processes
running in the same data directory and can also be used for
shutting down the edb-postmaster process.
There are several common reasons the server might fail to
start. Check the server's log file, or start it manually (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 edb-postmaster already running on port 5444?
HINT: 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 edb-postmaster 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 may
be a different problem. For example, trying to start an edb-postmaster
on a reserved port number may draw something like:
$ edb-postmaster -p 5444
LOG: could not bind IPv4 socket: Permission denied
HINT: Is another edb-postmaster already running on port 5444?
HINT: If not, wait a few seconds and retry.
FATAL: could not create TCP/IP listen socket
A message like
FATAL: could not create shared memory segment: Invalid argument
DETAIL: Failed system call was shmget(key=5440001, size=4011376640, 03600).
probably means your kernel's limit on the size of shared memory is
smaller than the work area EnterpriseDB
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 (-B switch). You will eventually want
to reconfigure your kernel to increase the allowed shared memory
size. You may 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
EnterpriseDB wants to create. As above,
you may be able to work around the problem by starting the
server with a reduced number of allowed connections
(-N switch), 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 V
IPC facilities are given in Section 30.5.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 up. Conditions other than
those shown below should be documented with the respective client
application.
edb-psql: could not connect to server: Connection refused
Is the server running on host "server.joe.com" and accepting
TCP/IP connections on port 5444?
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:
edb-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.5444"?
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 33.3.) Other error messages
such as Connection timed out may
indicate more fundamental problems, like lack of network
connectivity.