18.3. Starting the database server
Before anyone can access the database, you must start the database server. The database server program is postgres, and it must know where to find the data it needs. This is achieved with the -D option. Therefore, the easiest way to start the server is:
$ postgres -D /usr/local/pgsql/data
This will put the server running in the foreground. This step must also be logged in with a PostgreSQL user account to operate. If there is no -D option, the server will try to use the directory named by the environment variable PGDATA. If this environment variable is not provided, it will fail.
It is usually best to start postgres in the background. To do this, use the usual Unix shell syntax:
$ postgres -D /usr/local/pgsql/data >logfile 2>&1 &
As shown above, it is very important to store the stdout and stderr output of the server somewhere. This will be helpful for audit purposes and diagnosing problems (see (Section 24.3) for a more in-depth discussion of log file processing.
postgres also accepts some other command line options. For more information, see the postgres reference page and Chapter 19 below. These shell syntax can easily get boring. Therefore, we provide a wrapper program pg_ctl to simplify some tasks.
E.g:
pg_ctl start -l logfile
Will start the server in the background and put the output in the specified log file. The -D option is the same as in postgres. pg_ctl can also be used to stop the server.
Usually, you will want to start the database server when the computer starts. The automatic startup script is operating system dependent. PostgreSQL provides several in the contrib/start-scripts directory. Installation will require root privileges.
Different systems have different habits of starting the daemon at boot time. Many systems have a file /etc/rc.local or /etc/rc.d/rc.local. Others use the init.d or rc.d directory. No matter what you do, the server must be started by a PostgreSQL user account, not root or any other user. So you should probably use su postgres -c'...' in your command. E.g:
su postgres -c 'pg_ctl start -D /usr/local/pgsql/data -l serverlog'
Below are some suggestions that are more relevant to the operating system (in each case, make sure to use the correct installation directory and username where we show the common values).
- For FreeBSD, find the file contrib/start-scripts/freebsd in the PostgreSQL source distribution.
- On OpenBSD, add the following lines to the /etc/rc.local file:
if [ -x /usr/local/pgsql/bin/pg_ctl -a -x /usr/local/pgsql/bin/postgres ];
then
su -l postgres -c '/usr/local/pgsql/bin/pg_ctl start -s -l /var/
postgresql/log -D /usr/local/pgsql/data'
echo -n ' postgresql'
fi
- It will be
/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/dataadded to/etc/rc.d/rc.localor in the Linux system/etc/rc.local. You can also find the files in the PostgreSQL source code releasecontrib/start-scripts/linux.
When using systemd, you can use the following service unit files (for example, /etc/
systemd/system/postgresql.service）：
[Unit]
Description=PostgreSQL database server
Documentation=man:postgres(1)
[Service]
Type=notify
User=postgres
ExecStart=/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
ExecReload=/bin/kill -HUP $MAINPID
KillMode=mixed
KillSignal=SIGINT
TimeoutSec=0
[Install]
WantedBy=multi-user.target
Using Type=notify requires that the binary file of the server be compiled with configure --with-systemd.
Carefully consider the timeout setting. At the time of writing this document, systemd's default timeout period is 90 seconds and will kill processes that have not reported ready within this period. However, the PostgreSQL server may cause the startup process to exceed the default time greatly due to crash recovery. The recommended value is 0 to disable the timeout logic.
- On NetBSD, you can choose FreeBSD or Linux startup scripts according to your preference.
- On Solaris, create a file named /etc/init.d/postgresql with the following lines:
su - postgres -c "/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data"
Then create a symbolic link S99postgresql pointing to it in /etc/rc3.d.
When the server is running, its PID is saved in the postmaster.pid file in the data directory. This can prevent multiple server instances from running in the same data directory, and can also be used to shut down the server.
18.3.1. Server failed to start
There are several common reasons why the server fails to start. By checking the server log or using a manual start method (without redirecting standard output or standard error), you can see what error messages appear. Below we explain in detail some of the most common error messages.
LOG: could not bind IPv4 address "127.0.0.1": 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 any TCP/IP sockets
As the message says, this means: you are trying to start another server on a port where the server is already running. However, if the core error message is not Address already in useor its variants, it may be something else. For example, trying to start the server on a reserved port will receive the following message:
$ postgres -p 666
LOG: could not bind IPv4 address "127.0.0.1": Permission denied
HINT: Is another postmaster already running on port 666? If not, wait a few
seconds and retry.
FATAL: could not create any TCP/IP sockets
Messages like this:
FATAL: could not create shared memory segment: Invalid argument
DETAIL: Failed system call was shmget(key=5440001, size=4011376640, 03600).
It may mean that your kernel's limit on the shared memory area is smaller than the work area PostgreSQL is trying to create (4011376640 bytes in this example). Or it may mean that no System-V style shared memory support is configured in your kernel at all. As a temporary solution, you can try to start the server with less than the normal number of buffers (shared_buffers). You will eventually want to reconfigure the kernel to increase the allowable size of shared memory. This error will also be reported when you try to start multiple servers on the same machine, and the total space they require exceeds the limit of the kernel. An error like this:
FATAL: could not create semaphores: No space left on device
DETAIL: Failed system call was semget(5440126, 17, 03600).
It does not mean that you have run out of disk space. It means that your kernel's limit on System V semaphores is less than the number PostgreSQL wants to create. As above, you can circumvent this limit by reducing the number of allowed connections (max_connections), but in the end you still want to increase the kernel limit.
If you receive an "illegal system call" error, it is likely that your kernel does not support shared memory or semaphores at all. Your only option in this case is to reconfigure the kernel and turn on these features. For details on configuring System V IPC functions, see Section 18.4.1.
18.3.2. Client connection issues
Although the error conditions that may occur on the client side are wide-ranging and application-related, there are indeed several that are directly related to the way the server is started. All issues other than the errors mentioned below should be in the corresponding client application documentation.
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 common "I couldn't find a server to talk to" failure. The above situation seems to happen when trying TCP/IP communication. A common mistake is to forget to configure the server to allow TCP/IP connections.
In addition, when trying to communicate with the local server through a Unix domain socket, you will see this:
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 verifies that the client is trying to connect to the correct location. If no server is actually running there, the typical core error message will be Connection refusedor No such file or directory(It is worth noting that Connection refused in this environment does not mean that the server got your connection request and rejected it. That situation will produce a Different messages, as shown in Section 20.15). Other Connection timed outmessages like this may indicate more basic problems, such as lack of network connectivity.