17.3. Starting the Database Server
Important
In binary installations on Linux systems, the default database is located in/var/lib/pgpro/std-10/data, unless you specify a custom directory. SeeSection 16.1 for details.
Before anyone can access the database, you must start the database server. The database server program is calledpostgres. Thepostgres 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 thePostgres Pro user account. Without-D, the server will try to use the data directory named by the environment variablePGDATA. If that variable is not provided either, it will fail.
Normally it is better to startpostgres 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'sstdout andstderr output somewhere, as shown above. It will help for auditing purposes and to diagnose problems. (SeeSection 23.3 for a more thorough discussion of log file handling.)
Thepostgres program also takes a number of other command-line options. For more information, see thepostgres reference page andChapter 18 below.
This shell syntax can get tedious quickly. Therefore the wrapper programpg_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 forpostgres.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 withPostgres Pro in thecontrib/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 useinit.d orrc.d directories. Whatever you do, the server must be run by thePostgres Pro user accountand not by root or any other user. Therefore you probably should form your commands usingsu 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.)
ForFreeBSD, look at the file
contrib/start-scripts/freebsdin thePostgres Pro source distribution.OnOpenBSD, add the following lines to the file
/etc/rc.local: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
/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data
to
/etc/rc.d/rc.localor/etc/rc.localor look at the filecontrib/start-scripts/linuxin thePostgres Pro source distribution.When usingsystemd, you can use the following service unit file (e.g., at
/etc/systemd/system/postgresql.service):[Unit]Description=Postgres Pro database serverDocumentation=man:postgres(1)After=network-online.targetWants=network-online.target[Service]Type=notifyUser=postgresExecStart=/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/dataExecReload=/bin/kill -HUP $MAINPIDKillMode=mixedKillSignal=SIGINTTimeoutSec=infinity[Install]WantedBy=multi-user.target
Using
Type=notifyrequires that the server binary was built withconfigure --with-systemd.Consider carefully the timeout setting.systemd has a default timeout of 90 seconds as of this writing and will kill a process that does not notify readiness within that time. But aPostgres Pro server that might have to perform crash recovery at startup could take much longer to become ready. The suggested value of
infinitydisables the timeout logic.OnNetBSD, use either theFreeBSD orLinux start scripts, depending on preference.
OnSolaris, create a file called
/etc/init.d/postgresqlthat contains the following line:su - postgres -c "/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data"
Then, create a symbolic link to it in
/etc/rc3.dasS99postgresql.
While the server is running, itsPID is stored in the file 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. 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 A message like: probably means your kernel's limit on the size of shared memory is smaller than the work areaPostgres Pro 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: doesnot mean you've run out of disk space. It means your kernel's limit on the number ofSystem V semaphores is smaller than the numberPostgres Pro 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 configuringSystem VIPC facilities are given inSection 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. 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: 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 eitherpostmaster.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.17.3.1. Server Start-up Failures
LOG: could not bind IPv4 address "127.0.0.1": Address already in useHINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry.FATAL: could not create any TCP/IP sockets
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 666LOG: could not bind IPv4 address "127.0.0.1": Permission deniedHINT: Is another postmaster already running on port 666? If not, wait a few seconds and retry.FATAL: could not create any TCP/IP socketsFATAL: could not create shared memory segment: Invalid argumentDETAIL: Failed system call was shmget(key=5440001, size=4011376640, 03600).
FATAL: could not create semaphores: No space left on deviceDETAIL: Failed system call was semget(5440126, 17, 03600).
17.3.2. Client Connection Problems
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?
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"?
Connection refused orNo such file or directory, as illustrated. (It is important to realize thatConnection refused in this context doesnot mean that the server got your connection request and rejected it. That case will produce a different message, as shown inSection 19.4.) Other error messages such asConnection timed out might indicate more fundamental problems, like lack of network connectivity.