postgres [ option... ]
postgres is the PostgreSQL database server. In order for a client application to access a database it connects (over a network or locally) to a running postgres instance. The postgres instance then starts a separate server process to handle the connection.
One postgres instance always manages the data of exactly one database cluster. A database cluster is a collection of databases that is stored at a common file system location (the ``data area''). More than one postgres instance can run on a system at one time, so long as they use different data areas and different communication ports (see below). When postgres starts it needs to know the location of the data area. The location must be specified by the -D option or the PGDATA environment variable; there is no default. Typically, -D or PGDATA points directly to the data area directory created by initdb(1). Other possible file layouts are discussed in in the documentation.
By default postgres starts in the foreground and prints log messages to the standard error stream. In practical applications postgres should be started as a background process, perhaps at boot time.
The postgres command can also be called in single-user mode. The primary use for this mode is during bootstrapping by initdb(1). Sometimes it is used for debugging or disaster recovery (but note that running a single-user server is not truly suitable for debugging the server, since no realistic interprocess communication and locking will happen). When invoked in single-user mode from the shell, the user can enter queries and the results will be printed to the screen, but in a form that is more useful for developers than end users. In the single-user mode, the session user will be set to the user with ID 1, and implicit superuser powers are granted to this user. This user does not actually have to exist, so the single-user mode can be used to manually recover from certain kinds of accidental damage to the system catalogs.
postgres accepts the following command-line arguments. For a detailed discussion of the options consult in the documentation. You can save typing most of these options by setting up a configuration file. Some (safe) options can also be set from the connecting client in an application-dependent way to apply only for that session. For example, if the environment variable PGOPTIONS is set, then libpq-based clients will pass that string to the server, which will interpret it as postgres command-line options.
This option is deprecated since it does not allow access to the full functionality of listen_addresses. It's usually better to set listen_addresses directly.
The use of this option is obsolete; all command-line options for server processes can be specified directly on the postgres command line.
The options described here are used mainly for debugging purposes, and in some cases to assist with recovery of severely damaged databases. There should be no reason to use them in a production database setup. They are listed here only for use by PostgreSQL system developers. Furthermore, these options might change or be removed in a future release without notice.
Neither sequential scans nor nested-loop joins can be disabled completely; the -fs and -fn options simply discourage the optimizer from using those plan types if it has any other alternative.
The following options only apply to the single-user mode.
A failure message mentioning semget or shmget probably indicates you need to configure your kernel to provide adequate shared memory and semaphores. For more discussion see in the documentation. You might be able to postpone reconfiguring your kernel by decreasing shared_buffers to reduce the shared memory consumption of PostgreSQL, and/or by reducing max_connections to reduce the semaphore consumption.
A failure message suggesting that another server is already running should be checked carefully, for example by using the command
$ ps ax | grep postgresor
$ ps -ef | grep postgresdepending on your system. If you are certain that no conflicting server is running, you can remove the lock file mentioned in the message and try again.
A failure message indicating inability to bind to a port might indicate that that port is already in use by some non-PostgreSQL process. You might also get this error if you terminate postgres and immediately restart it using the same port; in this case, you must simply wait a few seconds until the operating system closes the port before trying again. Finally, you might get this error if you specify a port number that your operating system considers to be reserved. For example, many versions of Unix consider port numbers under 1024 to be ``trusted'' and only permit the Unix superuser to access them.
The utility command pg_ctl(1) can be used to start and shut down the postgres server safely and comfortably.
If at all possible, do not use SIGKILL to kill the main postgres server. Doing so will prevent postgres from freeing the system resources (e.g., shared memory and semaphores) that it holds before terminating. This might cause problems for starting a fresh postgres run.
To terminate the postgres server normally, the signals SIGTERM, SIGINT, or SIGQUIT can be used. The first will wait for all clients to terminate before quitting, the second will forcefully disconnect all clients, and the third will quit immediately without proper shutdown, resulting in a recovery run during restart.
The SIGHUP signal will reload the server configuration files. It is also possible to send SIGHUP to an individual server process, but that is usually not sensible.
To cancel a running query, send the SIGINT signal to the process running that command.
The postgres server uses SIGTERM to tell subordinate server processes to quit normally and SIGQUIT to terminate without the normal cleanup. These signals should not be used by users. It is also unwise to send SIGKILL to a server process --- the main postgres process will interpret this as a crash and will force all the sibling processes to quit as part of its standard crash-recovery procedure.
The -- options will not work on FreeBSD or OpenBSD. Use -c instead. This is a bug in the affected operating systems; a future release of PostgreSQL will provide a workaround if this is not fixed.
To start a single-user mode server, use a command like
postgres --single -D /usr/local/pgsql/data other-options my_databaseProvide the correct path to the database directory with -D, or make sure that the environment variable PGDATA is set. Also specify the name of the particular database you want to work in.
Normally, the single-user mode server treats newline as the command entry terminator; there is no intelligence about semicolons, as there is in psql. To continue a command across multiple lines, you must type backslash just before each newline except the last one.
But if you use the -j command line switch, then newline does not terminate command entry. In this case, the server will read the standard input until the end-of-file (EOF) marker, then process the input as a single command string. Backslash-newline is not treated specially in this case.
To quit the session, type EOF (Control+D, usually). If you've used -j, two consecutive EOFs are needed to exit.
Note that the single-user mode server does not provide sophisticated line-editing features (no command history, for example).
To start postgres in the background using default values, type:
$ nohup postgres >logfile 2>&1 </dev/null &
To start postgres with a specific port:
$ postgres -p 1234This command will start up postgres communicating through the port 1234. In order to connect to this server using psql, you would need to run it as
$ psql -p 1234or set the environment variable PGPORT:
$ export PGPORT=1234 $ psql
Named run-time parameters can be set in either of these styles:
$ postgres -c work_mem=1234 $ postgres --work-mem=1234Either form overrides whatever setting might exist for work_mem in postgresql.conf. Notice that underscores in parameter names can be written as either underscore or dash on the command line. Except for short-term experiments, it's probably better practice to edit the setting in postgresql.conf than to rely on a command-line switch to set a parameter.