Movatterモバイル変換

18.3.1. Server Start-up Failures

18.3.2. Client Connection Problems

• ForFreeBSD, look at the filecontrib/start-scripts/freebsd in thePostgreSQL 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

• OnLinux systems either add

  /usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data

  to/etc/rc.d/rc.local or/etc/rc.local or look at the filecontrib/start-scripts/linux in thePostgreSQL source distribution.

  When usingsystemd, you can use the following service unit file (e.g., at/etc/systemd/system/postgresql.service):

  [Unit]Description=PostgreSQL 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

  UsingType=notify requires 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 report readiness within that time. But aPostgreSQL server that might have to perform crash recovery at startup could take much longer to become ready. The suggested value ofinfinity disables the timeout logic.

• OnNetBSD, use either theFreeBSD orLinux start scripts, depending on preference.

• OnSolaris, create a file called/etc/init.d/postgresql that 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.d asS99postgresql.

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 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

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 notAddress 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 sockets

A message like:

FATAL:  could not create shared memory segment: Invalid argumentDETAIL:  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 areaPostgreSQL is trying to create (4011376640 bytes in this example). This is only likely to happen if you have setshared_memory_type tosysv. In that case, you can try starting the server with a smaller-than-normal number of buffers (shared_buffers), or 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 deviceDETAIL:  Failed system call was semget(5440126, 17, 03600).

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 numberPostgreSQL 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.

Details about configuringSystem VIPC facilities are given inSection 18.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: error: connection to server at "server.joe.com" (123.123.123.123), port 5432 failed: Connection refused        Is the server running on that host and accepting TCP/IP connections?

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 might get this when attempting Unix-domain socket communication to a local server:

psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: No such file or directory        Is the server running locally and accepting connections on that socket?

If the server is indeed running, check that the client's idea of the socket path (here/tmp) agrees with the server'sunix_socket_directories setting.

A connection failure message always shows the server address or socket path name, which is useful in verifying that the client is trying to connect to the right place. If there is in fact no server listening there, the kernel error message will typically be eitherConnection 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 20.15.) Other error messages such asConnection timed out might indicate more fundamental problems, like lack of network connectivity, or a firewall blocking the connection.