mirror of
https://github.com/postgres/postgres.git
synced 2025-07-30 11:03:19 +03:00
Merge postmaster and postgres command into just postgres. postmaster
symlink is kept for now for compatibility. To call single-user mode, use postgres --single.
This commit is contained in:
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/arch-dev.sgml,v 2.26 2006/03/10 19:10:46 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/arch-dev.sgml,v 2.27 2006/06/18 15:38:35 petere Exp $ -->
|
||||
|
||||
<chapter id="overview">
|
||||
<title>Overview of PostgreSQL Internals</title>
|
||||
@ -124,13 +124,11 @@
|
||||
know ahead of time how many connections will be made, we have to
|
||||
use a <firstterm>master process</firstterm> that spawns a new
|
||||
server process every time a connection is requested. This master
|
||||
process is called <literal>postmaster</literal> and listens at a
|
||||
process is called <literal>postgres</literal> and listens at a
|
||||
specified TCP/IP port for incoming connections. Whenever a request
|
||||
for a connection is detected the <literal>postmaster</literal>
|
||||
process spawns a new server process called
|
||||
<literal>postgres</literal>. The server tasks
|
||||
(<literal>postgres</literal> processes) communicate with each
|
||||
other using <firstterm>semaphores</firstterm> and
|
||||
for a connection is detected the <literal>postgres</literal>
|
||||
process spawns a new server process. The server tasks
|
||||
communicate with each other using <firstterm>semaphores</firstterm> and
|
||||
<firstterm>shared memory</firstterm> to ensure data integrity
|
||||
throughout concurrent data access.
|
||||
</para>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.80 2006/04/23 03:39:48 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.81 2006/06/18 15:38:35 petere Exp $ -->
|
||||
|
||||
<chapter id="backup">
|
||||
<title>Backup and Restore</title>
|
||||
@ -296,7 +296,7 @@ tar -cf backup.tar /usr/local/pgsql/data
|
||||
(mainly because <command>tar</command> and similar tools do not take an
|
||||
atomic snapshot of the state of the file system at a point in
|
||||
time). Information about stopping the server can be found in
|
||||
<xref linkend="postmaster-shutdown">. Needless to say that you
|
||||
<xref linkend="server-shutdown">. Needless to say that you
|
||||
also need to shut down the server before restoring the data.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -778,7 +778,7 @@ SELECT pg_stop_backup();
|
||||
</para>
|
||||
|
||||
<para>
|
||||
It is also possible to make a backup dump while the postmaster is
|
||||
It is also possible to make a backup dump while the server is
|
||||
stopped. In this case, you obviously cannot use
|
||||
<function>pg_start_backup</> or <function>pg_stop_backup</>, and
|
||||
you will therefore be left to your own devices to keep track of which
|
||||
@ -796,7 +796,7 @@ SELECT pg_stop_backup();
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Stop the postmaster, if it's running.
|
||||
Stop the server, if it's running.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -853,9 +853,9 @@ SELECT pg_stop_backup();
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Start the postmaster. The postmaster will go into recovery mode and
|
||||
Start the server. The server will go into recovery mode and
|
||||
proceed to read through the archived WAL files it needs. Upon completion
|
||||
of the recovery process, the postmaster will rename
|
||||
of the recovery process, the server will rename
|
||||
<filename>recovery.conf</> to <filename>recovery.done</> (to prevent
|
||||
accidentally re-entering recovery mode in case of a crash later) and then
|
||||
commence normal database operations.
|
||||
@ -1269,7 +1269,7 @@ mv /usr/local/pgsql /usr/local/pgsql.old
|
||||
cd ~/postgresql-&version;
|
||||
gmake install
|
||||
initdb -D /usr/local/pgsql/data
|
||||
postmaster -D /usr/local/pgsql/data
|
||||
postgres -D /usr/local/pgsql/data
|
||||
psql -f backup postgres
|
||||
</programlisting>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.90 2006/06/16 15:16:16 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.91 2006/06/18 15:38:35 petere Exp $ -->
|
||||
|
||||
<chapter id="client-authentication">
|
||||
<title>Client Authentication</title>
|
||||
@ -436,10 +436,10 @@ hostnossl <replaceable>database</replaceable> <replaceable>user</replaceable>
|
||||
|
||||
<para>
|
||||
The <filename>pg_hba.conf</filename> file is read on start-up and when
|
||||
the main server process (<command>postmaster</>) receives a
|
||||
the main server process receives a
|
||||
<systemitem>SIGHUP</systemitem><indexterm><primary>SIGHUP</primary></indexterm>
|
||||
signal. If you edit the file on an
|
||||
active system, you will need to signal the <command>postmaster</>
|
||||
active system, you will need to signal the server
|
||||
(using <literal>pg_ctl reload</> or <literal>kill -HUP</>) to make it
|
||||
re-read the file.
|
||||
</para>
|
||||
@ -866,10 +866,10 @@ local db1,db2,@demodbs all md5
|
||||
|
||||
<para>
|
||||
The <filename>pg_ident.conf</filename> file is read on start-up and
|
||||
when the main server process (<command>postmaster</>) receives a
|
||||
when the main server process receives a
|
||||
<systemitem>SIGHUP</systemitem><indexterm><primary>SIGHUP</primary></indexterm>
|
||||
signal. If you edit the file on an
|
||||
active system, you will need to signal the <command>postmaster</>
|
||||
active system, you will need to signal the server
|
||||
(using <literal>pg_ctl reload</> or <literal>kill -HUP</>) to make it
|
||||
re-read the file.
|
||||
</para>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.64 2006/06/16 12:47:49 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.65 2006/06/18 15:38:35 petere Exp $ -->
|
||||
|
||||
<chapter Id="runtime-config">
|
||||
<title>Server Configuration</title>
|
||||
@ -69,10 +69,9 @@ include 'filename'
|
||||
<indexterm>
|
||||
<primary>SIGHUP</primary>
|
||||
</indexterm>
|
||||
The configuration file is reread whenever the
|
||||
<command>postmaster</command> process receives a
|
||||
The configuration file is reread whenever the main server process receives a
|
||||
<systemitem>SIGHUP</> signal (which is most easily sent by means
|
||||
of <literal>pg_ctl reload</>). The <command>postmaster</command>
|
||||
of <literal>pg_ctl reload</>). The main server process
|
||||
also propagates this signal to all currently running server
|
||||
processes so that existing sessions also get the new
|
||||
value. Alternatively, you can send the signal to a single server
|
||||
@ -83,9 +82,9 @@ include 'filename'
|
||||
|
||||
<para>
|
||||
A second way to set these configuration parameters is to give them
|
||||
as a command line option to the <command>postmaster</command>, such as:
|
||||
as a command-line option to the <command>postgres</command> command, such as:
|
||||
<programlisting>
|
||||
postmaster -c log_connections=yes -c log_destination='syslog'
|
||||
postgres -c log_connections=yes -c log_destination='syslog'
|
||||
</programlisting>
|
||||
Command-line options override any conflicting settings in
|
||||
<filename>postgresql.conf</filename>. Note that this means you won't
|
||||
@ -116,7 +115,7 @@ env PGOPTIONS='-c geqo=off' psql
|
||||
and <xref linkend="sql-alterdatabase" endterm="sql-alterdatabase-title">,
|
||||
respectively, are used to configure these settings. Per-database
|
||||
settings override anything received from the
|
||||
<command>postmaster</command> command-line or the configuration
|
||||
<command>postgres</command> command-line or the configuration
|
||||
file, and in turn are overridden by per-user settings; both are
|
||||
overridden by per-session settings.
|
||||
</para>
|
||||
@ -192,7 +191,7 @@ SET ENABLE_SEQSCAN TO OFF;
|
||||
<para>
|
||||
Specifies the main server configuration file
|
||||
(customarily called <filename>postgresql.conf</>).
|
||||
This parameter can only be set on the postmaster command line.
|
||||
This parameter can only be set on the postgres command line.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -234,8 +233,7 @@ SET ENABLE_SEQSCAN TO OFF;
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the name of an additional process-id (PID) file that the
|
||||
<application>postmaster</> should create for use by server
|
||||
administration programs.
|
||||
server should create for use by server administration programs.
|
||||
This parameter can only be set at server start.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -252,7 +250,7 @@ SET ENABLE_SEQSCAN TO OFF;
|
||||
|
||||
<para>
|
||||
If you wish to keep the configuration files elsewhere than the
|
||||
data directory, the postmaster's <option>-D</option>
|
||||
data directory, the postgres <option>-D</option>
|
||||
command-line option or <envar>PGDATA</envar> environment variable
|
||||
must point to the directory containing the configuration files,
|
||||
and the <varname>data_directory</> parameter must be set in
|
||||
@ -269,7 +267,7 @@ SET ENABLE_SEQSCAN TO OFF;
|
||||
individually using the parameters <varname>config_file</>,
|
||||
<varname>hba_file</> and/or <varname>ident_file</>.
|
||||
<varname>config_file</> can only be specified on the
|
||||
<command>postmaster</command> command line, but the others can be
|
||||
<command>postgres</command> command line, but the others can be
|
||||
set within the main configuration file. If all three parameters plus
|
||||
<varname>data_directory</> are explicitly set, then it is not necessary
|
||||
to specify <option>-D</option> or <envar>PGDATA</envar>.
|
||||
@ -277,7 +275,7 @@ SET ENABLE_SEQSCAN TO OFF;
|
||||
|
||||
<para>
|
||||
When setting any of these parameters, a relative path will be interpreted
|
||||
with respect to the directory in which the <command>postmaster</command>
|
||||
with respect to the directory in which <command>postgres</command>
|
||||
is started.
|
||||
</para>
|
||||
</sect1>
|
||||
@ -2679,7 +2677,7 @@ SELECT * FROM parent WHERE key = 2400;
|
||||
below - anything else that looks like an escape is ignored. Other
|
||||
characters are copied straight to the log line. Some escapes are
|
||||
only recognized by session processes, and do not apply to
|
||||
background processes such as the postmaster. <application>Syslog</>
|
||||
background processes such as the main server process. <application>Syslog</>
|
||||
produces its own
|
||||
time stamp and process ID information, so you probably do not want to
|
||||
use those escapes if you are using <application>syslog</>.
|
||||
@ -3467,7 +3465,7 @@ SELECT * FROM parent WHERE key = 2400;
|
||||
|
||||
<para>
|
||||
Only superusers can change this setting, because it affects the
|
||||
messages sent to the postmaster log as well as to the client.
|
||||
messages sent to the server log as well as to the client.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.167 2006/04/23 03:39:49 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.168 2006/06/18 15:38:35 petere Exp $ -->
|
||||
|
||||
<chapter id="datatype">
|
||||
<title id="datatype-title">Data Types</title>
|
||||
@ -2153,7 +2153,7 @@ January 8 04:05:06 1999 PST
|
||||
<listitem>
|
||||
<para>
|
||||
If <varname>timezone</> is not specified in
|
||||
<filename>postgresql.conf</> nor as a postmaster command-line switch,
|
||||
<filename>postgresql.conf</> nor as a server command-line option,
|
||||
the server attempts to use the value of the <envar>TZ</envar>
|
||||
environment variable as the default time zone. If <envar>TZ</envar>
|
||||
is not defined or is not any of the time zone names known to
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.321 2006/06/15 17:52:48 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.322 2006/06/18 15:38:35 petere Exp $ -->
|
||||
|
||||
<chapter id="functions">
|
||||
<title>Functions and Operators</title>
|
||||
@ -8935,7 +8935,7 @@ select current_date + s.a as dates from generate_series(0,14,7) as s(a);
|
||||
<row>
|
||||
<entry><literal><function>pg_postmaster_start_time</function>()</literal></entry>
|
||||
<entry><type>timestamp with time zone</type></entry>
|
||||
<entry><command>postmaster</> start time</entry>
|
||||
<entry>server start time</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
@ -9044,7 +9044,7 @@ SET search_path TO <replaceable>schema</> <optional>, <replaceable>schema</>, ..
|
||||
<para>
|
||||
<function>pg_postmaster_start_time</function> returns the
|
||||
<type>timestamp with time zone</type> when the
|
||||
<command>postmaster</> started.
|
||||
server started.
|
||||
</para>
|
||||
|
||||
<indexterm zone="functions-info">
|
||||
@ -9850,7 +9850,7 @@ SELECT set_config('log_statement_stats', 'off', false);
|
||||
|
||||
<para>
|
||||
<function>pg_reload_conf</> sends a <systemitem>SIGHUP</> signal
|
||||
to the <application>postmaster</>, causing the configuration files
|
||||
to the server, causing the configuration files
|
||||
to be reloaded by all server processes.
|
||||
</para>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.257 2006/06/16 15:16:16 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.258 2006/06/18 15:38:35 petere Exp $ -->
|
||||
|
||||
<chapter id="installation">
|
||||
<title><![%standalone-include[<productname>PostgreSQL</>]]>
|
||||
@ -33,7 +33,7 @@ mkdir /usr/local/pgsql/data
|
||||
chown postgres /usr/local/pgsql/data
|
||||
su - postgres
|
||||
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
|
||||
/usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data >logfile 2>&1 &
|
||||
/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data >logfile 2>&1 &
|
||||
/usr/local/pgsql/bin/createdb test
|
||||
/usr/local/pgsql/bin/psql test
|
||||
</synopsis>
|
||||
@ -463,7 +463,7 @@ su - postgres
|
||||
(which you already have if you are upgrading).
|
||||
<programlisting>
|
||||
<userinput>/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data</>
|
||||
<userinput>/usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data</>
|
||||
<userinput>/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data</>
|
||||
</programlisting>
|
||||
Finally, restore your data with
|
||||
<screen>
|
||||
@ -1638,12 +1638,12 @@ postgres$ <userinput>/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data</>
|
||||
database server. Do so now. The command should look something
|
||||
like
|
||||
<programlisting>
|
||||
/usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data
|
||||
/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
|
||||
</programlisting>
|
||||
This will start the server in the foreground. To put the server
|
||||
in the background use something like
|
||||
<programlisting>
|
||||
nohup /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data \
|
||||
nohup /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data \
|
||||
</dev/null >>server.log 2>&1 </dev/null &
|
||||
</programlisting>
|
||||
</para>
|
||||
@ -1654,12 +1654,6 @@ nohup /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data \
|
||||
kill `cat /usr/local/pgsql/data/postmaster.pid`
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In order to allow TCP/IP connections (rather than only Unix
|
||||
domain socket ones) you need to pass the <option>-i</> option to
|
||||
<filename>postmaster</>.
|
||||
</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.55 2006/04/23 03:39:52 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.56 2006/06/18 15:38:35 petere Exp $ -->
|
||||
|
||||
<chapter id="maintenance">
|
||||
<title>Routine Database Maintenance Tasks</title>
|
||||
@ -403,10 +403,10 @@ HINT: Stop the postmaster and use a standalone backend to VACUUM in "mydb".
|
||||
administrator recover without data loss, by manually executing the
|
||||
required <command>VACUUM</> commands. However, since the system will not
|
||||
execute commands once it has gone into the safety shutdown mode,
|
||||
the only way to do this is to stop the postmaster and use a standalone
|
||||
the only way to do this is to stop the server and use a single-user
|
||||
backend to execute <command>VACUUM</>. The shutdown mode is not enforced
|
||||
by a standalone backend. See the <xref linkend="app-postgres"> reference
|
||||
page for details about using a standalone backend.
|
||||
by a single-user backend. See the <xref linkend="app-postgres"> reference
|
||||
page for details about using a single-user backend.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -628,17 +628,17 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you simply direct the <systemitem>stderr</> of the
|
||||
<command>postmaster</command> into a
|
||||
If you simply direct the <systemitem>stderr</> of
|
||||
<command>postgres</command> into a
|
||||
file, you will have log output, but
|
||||
the only way to truncate the log file is to stop and restart
|
||||
the <command>postmaster</command>. This may be OK if you are using
|
||||
the server. This may be OK if you are using
|
||||
<productname>PostgreSQL</productname> in a development environment,
|
||||
but few production servers would find this behavior acceptable.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A better approach is to send the <command>postmaster</>'s
|
||||
A better approach is to send the server's
|
||||
<systemitem>stderr</> output to some type of log rotation program.
|
||||
There is a built-in log rotation program, which you can use by
|
||||
setting the configuration parameter <literal>redirect_stderr</> to
|
||||
@ -653,7 +653,7 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
|
||||
server software. For example, the <application>rotatelogs</application>
|
||||
tool included in the <productname>Apache</productname> distribution
|
||||
can be used with <productname>PostgreSQL</productname>. To do this,
|
||||
just pipe the <command>postmaster</>'s
|
||||
just pipe the server's
|
||||
<systemitem>stderr</> output to the desired program.
|
||||
If you start the server with
|
||||
<command>pg_ctl</>, then <systemitem>stderr</>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.46 2006/05/04 16:07:28 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.47 2006/06/18 15:38:35 petere Exp $ -->
|
||||
|
||||
<chapter id="managing-databases">
|
||||
<title>Managing Databases</title>
|
||||
@ -81,7 +81,7 @@ SELECT datname FROM pg_database;
|
||||
<para>
|
||||
In order to create a database, the <productname>PostgreSQL</>
|
||||
server must be up and running (see <xref
|
||||
linkend="postmaster-start">).
|
||||
linkend="server-start">).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -491,7 +491,7 @@ SELECT spcname FROM pg_tablespace;
|
||||
point to each of the non-built-in tablespaces defined in the cluster.
|
||||
Although not recommended, it is possible to adjust the tablespace
|
||||
layout by hand by redefining these links. Two warnings: do not do so
|
||||
while the postmaster is running; and after you restart the postmaster,
|
||||
while the server is running; and after you restart the server,
|
||||
update the <structname>pg_tablespace</> catalog to show the new
|
||||
locations. (If you do not, <literal>pg_dump</> will continue to show
|
||||
the old tablespace locations.)
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/monitoring.sgml,v 1.32 2006/05/19 19:08:26 alvherre Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/monitoring.sgml,v 1.33 2006/06/18 15:38:35 petere Exp $ -->
|
||||
|
||||
<chapter id="monitoring">
|
||||
<title>Monitoring Database Activity</title>
|
||||
@ -49,7 +49,7 @@
|
||||
|
||||
<screen>
|
||||
$ ps auxww | grep ^postgres
|
||||
postgres 960 0.0 1.1 6104 1480 pts/1 SN 13:17 0:00 postmaster -i
|
||||
postgres 960 0.0 1.1 6104 1480 pts/1 SN 13:17 0:00 postgres -i
|
||||
postgres 963 0.0 1.1 7084 1472 pts/1 SN 13:17 0:00 postgres: stats buffer process
|
||||
postgres 965 0.0 1.1 6152 1512 pts/1 SN 13:17 0:00 postgres: stats collector process
|
||||
postgres 998 0.0 2.3 6532 2992 pts/1 SN 13:18 0:00 postgres: tgl runbug 127.0.0.1 idle
|
||||
@ -60,7 +60,7 @@ postgres 1016 0.1 2.4 6532 3080 pts/1 SN 13:19 0:00 postgres: tgl reg
|
||||
(The appropriate invocation of <command>ps</> varies across different
|
||||
platforms, as do the details of what is shown. This example is from a
|
||||
recent Linux system.) The first process listed here is the
|
||||
<application>postmaster</>, the master server process. The command arguments
|
||||
the master server process. The command arguments
|
||||
shown for it are the same ones given when it was launched. The next two
|
||||
processes implement the statistics collector, which will be described in
|
||||
detail in the next section. (These will not be present if you have set
|
||||
@ -89,10 +89,10 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
||||
use <command>/usr/ucb/ps</command>, rather than
|
||||
<command>/bin/ps</command>. You also must use two <option>w</option>
|
||||
flags, not just one. In addition, your original invocation of the
|
||||
<command>postmaster</command> command must have a shorter
|
||||
<command>postgres</command> command must have a shorter
|
||||
<command>ps</command> status display than that provided by each
|
||||
server process. If you fail to do all three things, the <command>ps</>
|
||||
output for each server process will be the original <command>postmaster</>
|
||||
output for each server process will be the original <command>postgres</>
|
||||
command line.
|
||||
</para>
|
||||
</tip>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/problems.sgml,v 2.25 2006/03/10 19:10:48 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/problems.sgml,v 2.26 2006/06/18 15:38:36 petere Exp $ -->
|
||||
|
||||
<sect1 id="bug-reporting">
|
||||
<title>Bug Reporting Guidelines</title>
|
||||
@ -223,7 +223,7 @@
|
||||
<literal>SELECT version();</literal> to
|
||||
find out the version of the server you are connected to. Most executable
|
||||
programs also support a <option>--version</option> option; at least
|
||||
<literal>postmaster --version</literal> and <literal>psql --version</literal>
|
||||
<literal>postgres --version</literal> and <literal>psql --version</literal>
|
||||
should work.
|
||||
If the function or the options do not exist then your version is
|
||||
more than old enough to warrant an upgrade.
|
||||
@ -283,7 +283,7 @@
|
||||
are specifically talking about the backend server, mention that, do not
|
||||
just say <quote>PostgreSQL crashes</quote>. A crash of a single
|
||||
backend server process is quite different from crash of the parent
|
||||
<quote>postmaster</> process; please don't say <quote>the postmaster
|
||||
<quote>postgres</> process; please don't say <quote>the server
|
||||
crashed</> when you mean a single backend process went down, nor vice versa.
|
||||
Also, client programs such as the interactive frontend <quote><application>psql</application></quote>
|
||||
are completely separate from the backend. Please try to be specific
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/protocol.sgml,v 1.64 2006/03/03 19:54:09 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/protocol.sgml,v 1.65 2006/06/18 15:38:36 petere Exp $ -->
|
||||
|
||||
<chapter id="protocol">
|
||||
<title>Frontend/Backend Protocol</title>
|
||||
@ -1044,7 +1044,7 @@
|
||||
this case is effectively synchronous — but it is also possible
|
||||
for parameter status changes to occur because the administrator
|
||||
changed a configuration file and then sent the
|
||||
<systemitem>SIGHUP</systemitem> signal to the postmaster. Also,
|
||||
<systemitem>SIGHUP</systemitem> signal to the server. Also,
|
||||
if a <command>SET</command> command is rolled back, an appropriate
|
||||
ParameterStatus message will be generated to report the current
|
||||
effective value.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/alter_database.sgml,v 1.17 2005/10/13 22:44:51 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/alter_database.sgml,v 1.18 2006/06/18 15:38:36 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -55,7 +55,7 @@ ALTER DATABASE <replaceable class="PARAMETER">name</replaceable> OWNER TO <repla
|
||||
database, the specified value becomes the session default value.
|
||||
The database-specific default overrides whatever setting is present
|
||||
in <filename>postgresql.conf</> or has been received from the
|
||||
<command>postmaster</command> command line. Only the database
|
||||
<command>postgres</command> command line. Only the database
|
||||
owner or a superuser can change the session defaults for a
|
||||
database. Certain variables cannot be set this way, or can only be
|
||||
set by a superuser.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/alter_role.sgml,v 1.5 2006/04/25 14:56:04 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/alter_role.sgml,v 1.6 2006/06/18 15:38:36 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -81,7 +81,7 @@ ALTER ROLE <replaceable class="PARAMETER">name</replaceable> RESET <replaceable>
|
||||
a specified configuration variable. Whenever the role subsequently
|
||||
starts a new session, the specified value becomes the session default,
|
||||
overriding whatever setting is present in <filename>postgresql.conf</>
|
||||
or has been received from the <command>postmaster</command> command line.
|
||||
or has been received from the <command>postgres</command> command line.
|
||||
(For a role without <literal>LOGIN</> privilege, session defaults have
|
||||
no effect.)
|
||||
Ordinary roles can change their own session defaults.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/initdb.sgml,v 1.35 2005/06/21 04:02:31 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/initdb.sgml,v 1.36 2006/06/18 15:38:36 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -127,7 +127,7 @@ PostgreSQL documentation
|
||||
<command>initdb</command>, but you can avoid writing it by
|
||||
setting the <envar>PGDATA</envar> environment variable, which
|
||||
can be convenient since the database server
|
||||
(<command>postmaster</command>) can find the database
|
||||
(<command>postgres</command>) can find the database
|
||||
directory later by the same variable.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -287,7 +287,6 @@ PostgreSQL documentation
|
||||
|
||||
<simplelist type="inline">
|
||||
<member><xref linkend="app-postgres"></member>
|
||||
<member><xref linkend="app-postmaster"></member>
|
||||
</simplelist>
|
||||
</refsect1>
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/ipcclean.sgml,v 1.11 2005/01/04 03:58:16 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/ipcclean.sgml,v 1.12 2006/06/18 15:38:36 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -32,7 +32,7 @@ PostgreSQL documentation
|
||||
semaphore sets owned by the current user. It is intended to be
|
||||
used for cleaning up after a crashed
|
||||
<productname>PostgreSQL</productname> server (<xref
|
||||
linkend="app-postmaster">). Note that immediately restarting the
|
||||
linkend="app-postgres">). Note that immediately restarting the
|
||||
server will also clean up shared memory and semaphores, so this
|
||||
command is of little real utility.
|
||||
</para>
|
||||
@ -53,7 +53,7 @@ PostgreSQL documentation
|
||||
<para>
|
||||
This script is a hack, but in the many years since it was written,
|
||||
no one has come up with an equally effective and portable solution.
|
||||
Since the <command>postmaster</command> can now clean up by
|
||||
Since <command>postgres</command> can now clean up by
|
||||
itself, it is unlikely that <command>ipcclean</command> will be
|
||||
improved upon in the future.
|
||||
</para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/pg_ctl-ref.sgml,v 1.32 2005/11/04 23:14:02 petere Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/pg_ctl-ref.sgml,v 1.33 2006/06/18 15:38:36 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -92,7 +92,7 @@ PostgreSQL documentation
|
||||
<para>
|
||||
<application>pg_ctl</application> is a utility for starting,
|
||||
stopping, or restarting the <productname>PostgreSQL</productname>
|
||||
backend server (<xref linkend="app-postmaster">), or displaying the
|
||||
backend server (<xref linkend="app-postgres">), or displaying the
|
||||
status of a running server. Although the server can be started
|
||||
manually, <application>pg_ctl</application> encapsulates tasks such
|
||||
as redirecting log output and properly detaching from the terminal
|
||||
@ -109,7 +109,7 @@ PostgreSQL documentation
|
||||
standard output (not standard error). If no log file is chosen, the
|
||||
standard output of <application>pg_ctl</application> should be redirected
|
||||
to a file or piped to another process such as a log rotating program
|
||||
like <application>rotatelogs</>; otherwise the <command>postmaster</command>
|
||||
like <application>rotatelogs</>; otherwise <command>postgres</command>
|
||||
will write its output to the controlling terminal (from the background)
|
||||
and will not leave the shell's process group.
|
||||
</para>
|
||||
@ -129,13 +129,13 @@ PostgreSQL documentation
|
||||
|
||||
<para>
|
||||
<option>restart</option> mode effectively executes a stop followed
|
||||
by a start. This allows changing the <command>postmaster</command>
|
||||
by a start. This allows changing the <command>postgres</command>
|
||||
command-line options.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<option>reload</option> mode simply sends the
|
||||
<command>postmaster</command> process a <systemitem>SIGHUP</>
|
||||
<command>postgres</command> process a <systemitem>SIGHUP</>
|
||||
signal, causing it to reread its configuration files
|
||||
(<filename>postgresql.conf</filename>,
|
||||
<filename>pg_hba.conf</filename>, etc.). This allows changing of
|
||||
@ -215,7 +215,7 @@ PostgreSQL documentation
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies options to be passed directly to the
|
||||
<command>postmaster</command> command.
|
||||
<command>postgres</command> command.
|
||||
</para>
|
||||
<para>
|
||||
The options are usually surrounded by single or double
|
||||
@ -228,12 +228,12 @@ PostgreSQL documentation
|
||||
<term><option>-p <replaceable class="parameter">path</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the location of the <filename>postmaster</filename>
|
||||
executable. By default the <filename>postmaster</filename> executable is taken from the same
|
||||
Specifies the location of the <filename>postgres</filename>
|
||||
executable. By default the <filename>postgres</filename> executable is taken from the same
|
||||
directory as <command>pg_ctl</command>, or failing that, the hard-wired
|
||||
installation directory. It is not necessary to use this
|
||||
option unless you are doing something unusual and get errors
|
||||
that the <filename>postmaster</filename> executable was not found.
|
||||
that the <filename>postgres</filename> executable was not found.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -344,7 +344,7 @@ PostgreSQL documentation
|
||||
</variablelist>
|
||||
|
||||
<para>
|
||||
For others, see <xref linkend="app-postmaster">.
|
||||
For others, see <xref linkend="app-postgres">.
|
||||
</para>
|
||||
</refsect1>
|
||||
|
||||
@ -373,7 +373,7 @@ PostgreSQL documentation
|
||||
If this file exists in the data directory,
|
||||
<application>pg_ctl</application> (in <option>start</option>
|
||||
mode) will pass the contents of the file as options to the
|
||||
<command>postmaster</command> command, unless overridden by the
|
||||
<command>postgres</command> command, unless overridden by the
|
||||
<option>-o</option> option.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -385,8 +385,8 @@ PostgreSQL documentation
|
||||
<listitem>
|
||||
<para>If this file exists in the data directory,
|
||||
<application>pg_ctl</application> (in <option>restart</option> mode)
|
||||
will pass the contents of the file as options to the
|
||||
<application>postmaster</application>, unless overridden
|
||||
will pass the contents of the file as options to
|
||||
<application>postgres</application>, unless overridden
|
||||
by the <option>-o</option> option. The contents of this file
|
||||
are also displayed in <option>status</option> mode.
|
||||
</para>
|
||||
@ -500,9 +500,9 @@ PostgreSQL documentation
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>pg_ctl status</userinput>
|
||||
<computeroutput>
|
||||
pg_ctl: postmaster is running (pid: 13718)
|
||||
pg_ctl: server is running (pid: 13718)
|
||||
Command line was:
|
||||
/usr/local/pgsql/bin/postmaster '-D' '/usr/local/pgsql/data' '-p' '5433' '-B' '128'
|
||||
/usr/local/pgsql/bin/postgres '-D' '/usr/local/pgsql/data' '-p' '5433' '-B' '128'
|
||||
</computeroutput>
|
||||
</screen>
|
||||
This is the command line that would be invoked in restart mode.
|
||||
@ -515,7 +515,7 @@ Command line was:
|
||||
<title>See Also</title>
|
||||
|
||||
<para>
|
||||
<xref linkend="app-postmaster">
|
||||
<xref linkend="app-postgres">
|
||||
</para>
|
||||
</refsect1>
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/pg_resetxlog.sgml,v 1.15 2006/06/03 02:19:24 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/pg_resetxlog.sgml,v 1.16 2006/06/18 15:38:36 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -168,8 +168,7 @@ PostgreSQL documentation
|
||||
server crashed then a lock file may have been left
|
||||
behind; in that case you can remove the lock file to allow
|
||||
<command>pg_resetxlog</command> to run. But before you do
|
||||
so, make doubly certain that there
|
||||
is no <command>postmaster</command> nor any backend server process still alive.
|
||||
so, make doubly certain that there is no server process still alive.
|
||||
</para>
|
||||
</refsect1>
|
||||
|
||||
|
@ -1,29 +1,28 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/postgres-ref.sgml,v 1.46 2006/01/05 10:07:44 petere Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/postgres-ref.sgml,v 1.47 2006/06/18 15:38:36 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
<refentry id="APP-POSTGRES">
|
||||
<refentry id="app-postgres">
|
||||
<refmeta>
|
||||
<refentrytitle id="APP-POSTGRES-TITLE"><application>postgres</application></refentrytitle>
|
||||
<refentrytitle><application>postgres</application></refentrytitle>
|
||||
<manvolnum>1</manvolnum>
|
||||
<refmiscinfo>Application</refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>postgres</refname>
|
||||
<refpurpose>run a <productname>PostgreSQL</productname> server in single-user mode</refpurpose>
|
||||
<refpurpose><productname>PostgreSQL</productname> database server</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<indexterm zone="app-postgres">
|
||||
<primary>postgres (the program)</primary>
|
||||
<primary>postgres</primary>
|
||||
</indexterm>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<cmdsynopsis>
|
||||
<command>postgres</command>
|
||||
<arg rep="repeat"><replaceable>option</></arg>
|
||||
<arg choice="plain"><replaceable>database</replaceable></arg>
|
||||
</cmdsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
@ -31,85 +30,500 @@ PostgreSQL documentation
|
||||
<title>Description</title>
|
||||
|
||||
<para>
|
||||
The <command>postgres</command> executable is the actual
|
||||
<productname>PostgreSQL</productname> server process that processes
|
||||
SQL statements. It is normally not called directly; instead a
|
||||
<xref linkend="app-postmaster"> multiuser server is started.
|
||||
Conceptually, the <command>postmaster</command> starts a new
|
||||
<command>postgres</command> process for each connection.
|
||||
(<filename>postmaster</filename> and <filename>postgres</filename>
|
||||
are in fact the same program, and on most platforms the connection
|
||||
process is forked).
|
||||
<command>postgres</command> is the
|
||||
<productname>PostgreSQL</productname> database server. In order
|
||||
for a client application to access a database it connects (over a
|
||||
network or locally) to a running <command>postgres</command> process.
|
||||
The <command>postgres</command> instance then starts a separate server
|
||||
process to handle the connection.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If the <command>postgres</command> command is called directly, it
|
||||
invokes the server in interactive single-user mode. The primary
|
||||
use for this mode is during bootstrapping by <xref
|
||||
linkend="app-initdb">. Sometimes it is used for debugging or
|
||||
disaster recovery.
|
||||
When invoked in interactive 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. 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.
|
||||
One <command>postgres</command> instance always manages the data from
|
||||
exactly one database cluster. A database cluster is a collection
|
||||
of databases that is stored at a common file system location (the
|
||||
<quote>data area</quote>). More than one
|
||||
<command>postgres</command> process can run on a system at one
|
||||
time, so long as they use different data areas and different
|
||||
communication ports (see below). When
|
||||
<command>postgres</command> starts it needs to know the location
|
||||
of the data area. The location must be specified by the
|
||||
<option>-D</option> option or the <envar>PGDATA</envar> environment
|
||||
variable; there is no default. Typically, <option>-D</option> or
|
||||
<envar>PGDATA</envar> points directly to the data area directory
|
||||
created by <application>initdb</>. Other possible file layouts are
|
||||
discussed in <xref linkend="runtime-config-file-locations">. A
|
||||
data area is created with <xref linkend="app-initdb">.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
When running a stand-alone server, the session user will be set to
|
||||
the user with ID 1. This user does not actually have to exist, so
|
||||
a stand-alone server can be used to manually recover from certain
|
||||
By default <command>postgres</command> starts in the
|
||||
foreground and prints log messages to the standard error stream. In
|
||||
practical applications the <command>postgres</command>
|
||||
should be started as a background process, perhaps at boot time.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <command>postgres</command> command can also be called in
|
||||
single-user mode. The primary use for this mode is during
|
||||
bootstrapping by <xref linkend="app-initdb">. Sometimes it is used
|
||||
for debugging or disaster recovery. When invoked in interactive
|
||||
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. 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
|
||||
running a stand-alone server, the session user will be set to the
|
||||
user with ID 1. This user does not actually have to exist, so a
|
||||
stand-alone server can be used to manually recover from certain
|
||||
kinds of accidental damage to the system catalogs. Implicit
|
||||
superuser powers are granted to the user with ID 1 in stand-alone
|
||||
superuser powers are granted to the user with ID 1 in single-user
|
||||
mode.
|
||||
</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<refsect1 id="app-postgres-options">
|
||||
<title>Options</title>
|
||||
|
||||
<para>
|
||||
When <command>postgres</command> is started by a <xref
|
||||
linkend="app-postmaster"> then it inherits all options set by the
|
||||
latter. In single-user mode, <command>postgres</command> accepts
|
||||
all the options that <command>postmaster</command> would accept.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can avoid having to type these options by setting up a
|
||||
configuration file. See <xref linkend="runtime-config"> for details. Some
|
||||
(safe) options can also be set from the connecting client in an
|
||||
application-dependent way. For example, if the environment
|
||||
variable <envar>PGOPTIONS</envar> is set, then
|
||||
<application>libpq</>-based clients will pass that string to the
|
||||
server, which will interpret it as
|
||||
<command>postgres</command> accepts the following command-line
|
||||
arguments. For a detailed discussion of the options consult <xref
|
||||
linkend="runtime-config">. 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 <envar>PGOPTIONS</envar> is
|
||||
set, then <application>libpq</>-based clients will pass that
|
||||
string to the server, which will interpret it as
|
||||
<command>postgres</command> command-line options.
|
||||
</para>
|
||||
|
||||
<refsect2>
|
||||
<title>General Purpose</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><option>-A 0|1</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Enables run-time assertion checks, which is a debugging aid to
|
||||
detect programming mistakes. This option is only available if
|
||||
assertions were enabled when <productname>PostgreSQL</> was
|
||||
compiled. If so, the default is on.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<para>
|
||||
The options <option>-A</option>, <option>-B</option>,
|
||||
<option>-c</option>, <option>-d</option>, <option>-D</option>,
|
||||
<option>-e</option>, <option>-F</option>, <option>-s</option>,
|
||||
<option>-S</option>, and <option>--<replaceable>name</></option>
|
||||
have the same meanings as with the <xref linkend="app-postmaster">
|
||||
except that <literal>-d 0</> prevents the server log level of the
|
||||
<command>postmaster</> from being propagated to
|
||||
<command>postgres</>. Other <command>postmaster</command>
|
||||
options are also accepted but will have no noticeable effect
|
||||
because they only apply to the multiuser server mode, namely
|
||||
<option>-h</option>, <option>-i</option>, <option>-k</option>,
|
||||
<option>-l</option>, and <option>-n</option>.
|
||||
</para>
|
||||
<varlistentry>
|
||||
<term><option>-B <replaceable class="parameter">nbuffers</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Sets the number of shared buffers for use by the server
|
||||
processes. The default value of this parameter is chosen
|
||||
automatically by <application>initdb</application>; refer to <xref
|
||||
linkend="runtime-config-resource-memory"> for more information.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-c <replaceable>name</replaceable>=<replaceable>value</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Sets a named run-time parameter. The configuration parameters
|
||||
supported by <productname>PostgreSQL</productname> are
|
||||
described in <xref linkend="runtime-config">. Most of the
|
||||
other command line options are in fact short forms of such a
|
||||
parameter assignment. <option>-c</> can appear multiple times
|
||||
to set multiple parameters.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-d <replaceable>debug-level</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Sets the debug level. The higher this value is set, the more
|
||||
debugging output is written to the server log. Values are
|
||||
from 1 to 5. It is also possible to pass <literal>-d
|
||||
0</literal> for a specific session, which will prevent the
|
||||
server log level of the <command>postgres</> from being
|
||||
propagated to this session.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-D <replaceable class="parameter">datadir</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the file system location of the data directory or
|
||||
configuration file(s). See
|
||||
<xref linkend="runtime-config-file-locations"> for details.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-e</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Sets the default date style to <quote>European</quote>, that is
|
||||
<literal>DMY</> ordering of input date fields. This also causes
|
||||
the day to be printed before the month in certain date output formats.
|
||||
See <xref linkend="datatype-datetime"> for more information.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-F</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Disables <function>fsync</function> calls for improved
|
||||
performance, at the risk of data corruption in the event of a
|
||||
system crash. Specifying this option is equivalent to
|
||||
disabling the <xref linkend="guc-fsync"> configuration
|
||||
parameter. Read the detailed documentation before using this!
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<option>--fsync=true</option> has the opposite effect
|
||||
of this option.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-h <replaceable class="parameter">hostname</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the IP host name or address on which
|
||||
<command>postgres</command> is to listen for TCP/IP
|
||||
connections from client applications. The value can also be a
|
||||
comma-separated list of addresses, or <literal>*</> to specify
|
||||
listening on all available interfaces. An empty value
|
||||
specifies not listening on any IP addresses, in which case
|
||||
only Unix-domain sockets can be used to connect to the
|
||||
<command>postgres</command>. Defaults to listening only on
|
||||
<systemitem class="systemname">localhost</systemitem>.
|
||||
Specifying this option is equivalent to setting the <xref
|
||||
linkend="guc-listen-addresses"> configuration parameter.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-i</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Allows remote clients to connect via TCP/IP (Internet domain)
|
||||
connections. Without this option, only local connections are
|
||||
accepted. This option is equivalent to setting
|
||||
<varname>listen_addresses</> to <literal>*</> in
|
||||
<filename>postgresql.conf</> or via <option>-h</>.
|
||||
</para>
|
||||
<para>
|
||||
This option is deprecated since it does not allow access to the
|
||||
full functionality of <xref linkend="guc-listen-addresses">.
|
||||
It's usually better to set <varname>listen_addresses</> directly.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-k <replaceable class="parameter">directory</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the directory of the Unix-domain socket on which
|
||||
<command>postgres</command> is to listen for
|
||||
connections from client applications. The default is normally
|
||||
<filename>/tmp</filename>, but can be changed at build time.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-l</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Enables secure connections using <acronym>SSL</acronym>.
|
||||
<productname>PostgreSQL</productname> must have been compiled with
|
||||
support for <acronym>SSL</acronym> for this option to be
|
||||
available. For more information on using <acronym>SSL</acronym>,
|
||||
refer to <xref linkend="ssl-tcp">.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-N <replaceable class="parameter">max-connections</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Sets the maximum number of client connections that this
|
||||
<command>postgres</command> will accept. By
|
||||
default, this value is 32, but it can be set as high as your
|
||||
system will support. (Note that
|
||||
<option>-B</option> is required to be at least twice
|
||||
<option>-N</option>. See <xref linkend="kernel-resources"> for a discussion of
|
||||
system resource requirements for large numbers of client
|
||||
connections.) Specifying this option is equivalent to setting the
|
||||
<xref linkend="guc-max-connections"> configuration parameter.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-o <replaceable class="parameter">extra-options</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The command line-style options specified in <replaceable
|
||||
class="parameter">extra-options</replaceable> are passed to
|
||||
all server processes started by this
|
||||
<command>postgres</command>. If the option string contains
|
||||
any spaces, the entire string must be quoted.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The use of this option is obsolete; all command-line options
|
||||
for server processes can be specified directly on the
|
||||
<command>postgres</command> command line
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-p <replaceable class="parameter">port</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the TCP/IP port or local Unix domain socket file
|
||||
extension on which <command>postgres</command>
|
||||
is to listen for connections from client applications.
|
||||
Defaults to the value of the <envar>PGPORT</envar> environment
|
||||
variable, or if <envar>PGPORT</envar> is not set, then
|
||||
defaults to the value established during compilation (normally
|
||||
5432). If you specify a port other than the default port,
|
||||
then all client applications must specify the same port using
|
||||
either command-line options or <envar>PGPORT</envar>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-s</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Print time information and other statistics at the end of each command.
|
||||
This is useful for benchmarking or for use in tuning the number of
|
||||
buffers.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-S</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies that the <command>postgres</command>
|
||||
process should start up in silent mode. That is, it will
|
||||
disassociate from the user's (controlling) terminal, start its
|
||||
own process group, and redirect its standard output and
|
||||
standard error to <filename>/dev/null</filename>.
|
||||
</para>
|
||||
<para>
|
||||
Using this switch discards all logging output, which is
|
||||
probably not what you want, since it makes it very difficult
|
||||
to troubleshoot problems. See below for a better way to start
|
||||
<command>postgres</command> in the background.
|
||||
</para>
|
||||
<para>
|
||||
<option>--silent-mode=false</option> has the opposite effect
|
||||
of this option.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>--<replaceable>name</replaceable>=<replaceable>value</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Sets a named run-time parameter; a shorter form of
|
||||
<option>-c</>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>--describe-config</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This option dumps out the server's internal configuration variables,
|
||||
descriptions, and defaults in tab-delimited <command>COPY</> format.
|
||||
It is designed primarily for use by administration tools.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect2>
|
||||
|
||||
<refsect2>
|
||||
<title>Options for stand-alone mode</title>
|
||||
<title>Semi-internal Options</title>
|
||||
|
||||
<para>
|
||||
There are several other options that may be specified, 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. These are listed
|
||||
here only for the use by <productname>PostgreSQL</productname>
|
||||
system developers. Furthermore, any of these options may
|
||||
disappear or change in a future release without notice.
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><option>-f</option> <literal>{ s | i | m | n | h }</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Forbids the use of particular scan and join methods:
|
||||
<literal>s</literal> and <literal>i</literal>
|
||||
disable sequential and index scans respectively, while
|
||||
<literal>n</literal>, <literal>m</literal>, and <literal>h</literal>
|
||||
disable nested-loop, merge and hash joins respectively.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Neither sequential scans nor nested-loop joins can be disabled
|
||||
completely; the <literal>-fs</literal> and
|
||||
<literal>-fn</literal> options simply discourage the optimizer
|
||||
from using those plan types if it has any other alternative.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-n</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This option is for debugging problems that cause a server
|
||||
process to die abnormally. The ordinary strategy in this
|
||||
situation is to notify all other server processes that they
|
||||
must terminate and then reinitialize the shared memory and
|
||||
semaphores. This is because an errant server process could
|
||||
have corrupted some shared state before terminating. This
|
||||
option specifies that <command>postgres</command> will
|
||||
not reinitialize shared data structures. A knowledgeable
|
||||
system programmer can then use a debugger to examine shared
|
||||
memory and semaphore state.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-O</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Allows the structure of system tables to be modified. This is
|
||||
used by <command>initdb</command>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-P</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Ignore system indexes when reading system tables (but still update
|
||||
the indexes when modifying the tables). This is useful when
|
||||
recovering from damaged system indexes.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-t</option> <literal>pa[rser] | pl[anner] | e[xecutor]</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Print timing statistics for each query relating to each of the
|
||||
major system modules. This option cannot be used together
|
||||
with the <option>-s</option> option.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-T</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This option is for debugging problems that cause a server
|
||||
process to die abnormally. The ordinary strategy in this
|
||||
situation is to notify all other server processes that they
|
||||
must terminate and then reinitialize the shared memory and
|
||||
semaphores. This is because an errant server process could
|
||||
have corrupted some shared state before terminating. This
|
||||
option specifies that <command>postgres</command> will
|
||||
stop all other server processes by sending the signal
|
||||
<literal>SIGSTOP</literal>, but will not cause them to
|
||||
terminate. This permits system programmers to collect core
|
||||
dumps from all server processes by hand.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-v</option> <replaceable class="parameter">protocol</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the version number of the frontend/backend protocol
|
||||
to be used for a particular session. This option is for
|
||||
internal use only.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-W</option> <replaceable class="parameter">seconds</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
A delay of this many seconds occurs when a new server process
|
||||
is started, after it conducts the authentication procedure.
|
||||
This is intended to give an opportunity to attach to the
|
||||
server process with a debugger.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-y</option> <replaceable class="parameter">database</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Indicates that this is a subprocess started by
|
||||
<command>postgres</command> and specifies the database to
|
||||
use. This option is for internal use only.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect2>
|
||||
|
||||
<refsect2>
|
||||
<title>Options for single-user mode</title>
|
||||
|
||||
<para>
|
||||
The following options only apply to the single-user mode.
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><option>--single</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Selects the single-user mode. This must be the first argument
|
||||
on the command line.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><replaceable class="parameter">database</replaceable></term>
|
||||
<listitem>
|
||||
@ -142,69 +556,33 @@ PostgreSQL documentation
|
||||
<term><option>-r</option> <replaceable class="parameter">filename</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Send all server log output to
|
||||
<replaceable class="parameter">filename</replaceable>.
|
||||
If <command>postgres</command> is running under the
|
||||
<command>postmaster</command>, this option is ignored,
|
||||
and the <systemitem>stderr</> inherited from the
|
||||
<command>postmaster</command> is used.
|
||||
Send all server log output to <replaceable
|
||||
class="parameter">filename</replaceable>. In normal multiuser
|
||||
mode, this option is ignored, and <systemitem>stderr</> is
|
||||
used by all processes.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect2>
|
||||
|
||||
<refsect2>
|
||||
<title>Semi-internal Options</title>
|
||||
|
||||
<para>
|
||||
The options <option>-f</option>, <option>-O</option>,
|
||||
<option>-P</option>, <option>-t</option>, and <option>-W</option>
|
||||
have the same meanings as with the <xref
|
||||
linkend="app-postmaster"> and are reserved for debugging and
|
||||
disaster recovery. Further options for internal use are:
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><option>-v</option> <replaceable class="parameter">protocol</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the version number of the frontend/backend protocol
|
||||
to be used for this particular session.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-y</option> <replaceable class="parameter">database</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Indicates that this process has been started by a
|
||||
<command>postmaster</command> and specifies the database to use.
|
||||
etc.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>--describe-config</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This option dumps out the server's internal configuration variables,
|
||||
descriptions, and defaults in tab-delimited <command>COPY</> format.
|
||||
It is designed primarily for use by administration tools.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</para>
|
||||
</refsect2>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Environment</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><envar>PGCLIENTENCODING</envar></term>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Default character encoding used by clients. (The clients may
|
||||
override this individually.) This value can also be set in the
|
||||
configuration file.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>PGDATA</envar></term>
|
||||
|
||||
@ -214,47 +592,154 @@ PostgreSQL documentation
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>PGDATESTYLE</envar></term>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Default value of the <xref linkend="guc-datestyle"> run-time
|
||||
parameter. (The use of this environment variable is deprecated.)
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>PGPORT</envar></term>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Default port (preferably set in the configuration file)
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>TZ</envar></term>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Server time zone
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Diagnostics</title>
|
||||
|
||||
<para>
|
||||
A failure message mentioning <literal>semget</> or
|
||||
<literal>shmget</> probably indicates you need to configure your
|
||||
kernel to provide adequate shared memory and semaphores. For more
|
||||
discussion see <xref linkend="kernel-resources">. You may be able
|
||||
to postpone reconfiguring your kernel by decreasing <xref
|
||||
linkend="guc-shared-buffers"> to reduce the shared memory
|
||||
consumption of <productname>PostgreSQL</>, and/or by reducing
|
||||
<xref linkend="guc-max-connections"> to reduce the semaphore
|
||||
consumption.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A failure message suggesting that another server is already running
|
||||
should be checked carefully, for example by using the command
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>ps ax | grep postgres</userinput>
|
||||
</screen>
|
||||
or
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>ps -ef | grep postgres</userinput>
|
||||
</screen>
|
||||
depending on your system. If you are certain that no conflicting
|
||||
server is running, you may remove the lock file mentioned in the
|
||||
message and try again.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A failure message indicating inability to bind to a port may
|
||||
indicate that that port is already in use by some
|
||||
non-<productname>PostgreSQL</productname> process. You may also
|
||||
get this error if you terminate <command>postgres</command>
|
||||
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 may 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 <quote>trusted</quote> and only permit
|
||||
the Unix superuser to access them.
|
||||
</para>
|
||||
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Notes</title>
|
||||
|
||||
<para>
|
||||
If at all possible, <emphasis>do not</emphasis> use
|
||||
<literal>SIGKILL</literal> to kill the main
|
||||
<command>postgres</command> server. Doing so will prevent
|
||||
<command>postgres</command> from freeing the system
|
||||
resources (e.g., shared memory and semaphores) that it holds before
|
||||
terminating. This may cause problems for starting a fresh
|
||||
<command>postgres</command> run.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To terminate the <command>postgres</command> server normally, the
|
||||
signals <literal>SIGTERM</literal>, <literal>SIGINT</literal>, or
|
||||
<literal>SIGQUIT</literal> 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 <literal>SIGHUP</literal> signal will reload
|
||||
the server configuration files. It is also possible to send
|
||||
<literal>SIGHUP</literal> to an individual server process, but that
|
||||
is usually not sensible.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The utility command <xref linkend="app-pg-ctl"> can be used to
|
||||
start and shut down the <command>postgres</command> server
|
||||
safely and comfortably.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To cancel a running query, send the <literal>SIGINT</literal> signal
|
||||
to the <command>postgres</command> process running that command.
|
||||
to the process running that command.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To tell <command>postgres</command> to reload the configuration files,
|
||||
send a <literal>SIGHUP</literal> signal. Normally it's best to
|
||||
<literal>SIGHUP</literal> the <command>postmaster</command> instead;
|
||||
the <command>postmaster</command> will in turn <literal>SIGHUP</literal>
|
||||
each of its children. But in some cases it might be desirable to have only
|
||||
one <command>postgres</command> process reload the configuration files.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <command>postmaster</command> uses <literal>SIGTERM</literal>
|
||||
to tell a <command>postgres</command> process to quit normally and
|
||||
The <command>postgres</command> server uses <literal>SIGTERM</literal>
|
||||
to tell subordinate server processes to quit normally and
|
||||
<literal>SIGQUIT</literal> to terminate without the normal cleanup.
|
||||
These signals <emphasis>should not</emphasis> be used by users. It is also
|
||||
unwise to send <literal>SIGKILL</literal> to a <command>postgres</command>
|
||||
process — the <command>postmaster</command> will interpret this as
|
||||
a crash in <command>postgres</command>, and will force all the sibling
|
||||
<command>postgres</command> processes to quit as part of its standard
|
||||
crash-recovery procedure.
|
||||
These signals <emphasis>should not</emphasis> be used by users. It
|
||||
is also unwise to send <literal>SIGKILL</literal> to a server
|
||||
process — the main <command>postgres</command> process will
|
||||
interpret this as a crash and will force all the sibling processes
|
||||
to quit as part of its standard crash-recovery procedure.
|
||||
</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1 id="app-postgres-bugs">
|
||||
<title>Bugs</title>
|
||||
<para>
|
||||
The <option>--</> options will not work on <systemitem
|
||||
class="osname">FreeBSD</> or <systemitem class="osname">OpenBSD</>.
|
||||
Use <option>-c</> instead. This is a bug in the affected operating
|
||||
systems; a future release of <productname>PostgreSQL</productname>
|
||||
will provide a workaround if this is not fixed.
|
||||
</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Usage</title>
|
||||
|
||||
<para>
|
||||
Start a stand-alone server with a command like
|
||||
To start a single-user mode server, use a command like
|
||||
<screen>
|
||||
<userinput>postgres -D /usr/local/pgsql/data <replaceable>other-options</> my_database</userinput>
|
||||
<userinput>postgres --single -D /usr/local/pgsql/data <replaceable>other-options</> my_database</userinput>
|
||||
</screen>
|
||||
Provide the correct path to the database directory with <option>-D</>, or
|
||||
make sure that the environment variable <envar>PGDATA</> is set.
|
||||
@ -262,7 +747,7 @@ PostgreSQL documentation
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Normally, the stand-alone server treats newline as the command
|
||||
Normally, the single-user mode server treats newline as the command
|
||||
entry terminator; there is no intelligence about semicolons,
|
||||
as there is in <application>psql</>. To continue a command
|
||||
across multiple lines, you must type backslash just before each
|
||||
@ -285,10 +770,57 @@ PostgreSQL documentation
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Note that the stand-alone server does not provide sophisticated
|
||||
Note that the single-user mode server does not provide sophisticated
|
||||
line-editing features (no command history, for example).
|
||||
</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1 id="app-postgres-examples">
|
||||
<title>Examples</title>
|
||||
|
||||
<para>
|
||||
To start <command>postgres</command> in the background
|
||||
using default values, type:
|
||||
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>nohup postgres >logfile 2>&1 </dev/null &</userinput>
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To start <command>postgres</command> with a specific
|
||||
port:
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>postgres -p 1234</userinput>
|
||||
</screen>
|
||||
This command will start up <command>postgres</command>
|
||||
communicating through the port 1234. In order to connect to this
|
||||
<command>postgres</command> using <application>psql</>, you would need to
|
||||
run it as
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>psql -p 1234</userinput>
|
||||
</screen>
|
||||
or set the environment variable <envar>PGPORT</envar>:
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>export PGPORT=1234</userinput>
|
||||
<prompt>$</prompt> <userinput>psql</userinput>
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Named run-time parameters can be set in either of these styles:
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>postgres -c work_mem=1234</userinput>
|
||||
<prompt>$</prompt> <userinput>postgres --work-mem=1234</userinput>
|
||||
</screen>
|
||||
Either form overrides whatever setting might exist for
|
||||
<varname>work_mem</> in <filename>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
|
||||
<filename>postgresql.conf</> than to rely on a command-line switch
|
||||
to set a parameter.
|
||||
</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
@ -296,26 +828,7 @@ PostgreSQL documentation
|
||||
|
||||
<para>
|
||||
<xref linkend="app-initdb">,
|
||||
<xref linkend="app-ipcclean">,
|
||||
<xref linkend="app-postmaster">
|
||||
<xref linkend="app-pg-ctl">
|
||||
</para>
|
||||
</refsect1>
|
||||
|
||||
</refentry>
|
||||
|
||||
<!-- Keep this comment at the end of the file
|
||||
Local variables:
|
||||
mode: sgml
|
||||
sgml-omittag:nil
|
||||
sgml-shorttag:t
|
||||
sgml-minimize-attributes:nil
|
||||
sgml-always-quote-attributes:t
|
||||
sgml-indent-step:1
|
||||
sgml-indent-data:t
|
||||
sgml-parent-document:nil
|
||||
sgml-default-dtd-file:"../reference.ced"
|
||||
sgml-exposed-tags:nil
|
||||
sgml-local-catalogs:"/usr/lib/sgml/catalog"
|
||||
sgml-local-ecat-files:nil
|
||||
End:
|
||||
-->
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/postmaster.sgml,v 1.56 2006/01/06 01:35:09 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/postmaster.sgml,v 1.57 2006/06/18 15:38:36 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -12,7 +12,7 @@ PostgreSQL documentation
|
||||
|
||||
<refnamediv>
|
||||
<refname id="postmaster-ref">postmaster</refname>
|
||||
<refpurpose><productname>PostgreSQL</productname> multiuser database server</refpurpose>
|
||||
<refpurpose><productname>PostgreSQL</productname> database server</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<indexterm zone="app-postmaster">
|
||||
@ -30,659 +30,15 @@ PostgreSQL documentation
|
||||
<title>Description</title>
|
||||
|
||||
<para>
|
||||
<command>postmaster</command> is the
|
||||
<productname>PostgreSQL</productname> multiuser database server.
|
||||
In order for a client application to access a database it connects
|
||||
(over a network or locally) to a running
|
||||
<command>postmaster</command>. The
|
||||
<command>postmaster</command> then starts a separate server
|
||||
process (<quote><xref linkend="app-postgres"></quote>) to handle
|
||||
the connection. The <command>postmaster</command> also
|
||||
manages the communication among server processes.
|
||||
<command>postmaster</command> is a deprecated alias of <command>postgres</command>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
By default the <command>postmaster</command> starts in the
|
||||
foreground and prints log messages to the standard error stream. In
|
||||
practical applications the <command>postmaster</command>
|
||||
should be started as a background process, perhaps at boot time.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
One <command>postmaster</command> always manages the data
|
||||
from exactly one database cluster. A database cluster is a
|
||||
collection of databases that is stored at a common file system
|
||||
location (the <quote>data area</quote>).
|
||||
More than one <command>postmaster</command> process can run on a system
|
||||
at one time, so long as they use different data areas and different
|
||||
communication ports (see below).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
When the <command>postmaster</command> starts it needs
|
||||
to know the location of the data area.
|
||||
The location must be specified by the <option>-D</option> option
|
||||
or the <envar>PGDATA</envar> environment variable; there is no default.
|
||||
Typically, <option>-D</option> or <envar>PGDATA</envar> points
|
||||
directly to the data area directory created by <application>initdb</>.
|
||||
Other possible file layouts are discussed in
|
||||
<xref linkend="runtime-config-file-locations">.
|
||||
A data area is created with <xref linkend="app-initdb">.
|
||||
</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1 id="app-postmaster-options">
|
||||
<title>Options</title>
|
||||
|
||||
<para>
|
||||
<command>postmaster</command> accepts the following
|
||||
command line arguments. For a detailed discussion of the options
|
||||
consult <xref linkend="runtime-config">. You can save typing most of these
|
||||
options by setting up a configuration file.
|
||||
</para>
|
||||
|
||||
<refsect2>
|
||||
<title>General Purpose</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><option>-A 0|1</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Enables run-time assertion checks, which is a debugging aid to
|
||||
detect programming mistakes. This option is only available if
|
||||
assertions were enabled when <productname>PostgreSQL</> was
|
||||
compiled. If so, the default is on.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-B <replaceable class="parameter">nbuffers</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Sets the number of shared buffers for use by the server
|
||||
processes. The default value of this parameter is chosen
|
||||
automatically by <application>initdb</application>; refer to <xref
|
||||
linkend="runtime-config-resource-memory"> for more information.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-c <replaceable>name</replaceable>=<replaceable>value</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Sets a named run-time parameter. The configuration parameters
|
||||
supported by <productname>PostgreSQL</productname> are
|
||||
described in <xref linkend="runtime-config">. Most of the
|
||||
other command line options are in fact short forms of such a
|
||||
parameter assignment. <option>-c</> can appear multiple times
|
||||
to set multiple parameters.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-d <replaceable>debug-level</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Sets the debug level. The higher this value is set, the more
|
||||
debugging output is written to the server log. Values are from
|
||||
1 to 5.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-D <replaceable class="parameter">datadir</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the file system location of the data directory or
|
||||
configuration file(s). See
|
||||
<xref linkend="runtime-config-file-locations"> for details.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-e</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Sets the default date style to <quote>European</quote>, that is
|
||||
<literal>DMY</> ordering of input date fields. This also causes
|
||||
the day to be printed before the month in certain date output formats.
|
||||
See <xref linkend="datatype-datetime"> for more information.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-F</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Disables <function>fsync</function> calls for improved
|
||||
performance, at the risk of data corruption in the event of a
|
||||
system crash. Specifying this option is equivalent to
|
||||
disabling the <xref linkend="guc-fsync"> configuration
|
||||
parameter. Read the detailed documentation before using this!
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<option>--fsync=true</option> has the opposite effect
|
||||
of this option.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-h <replaceable class="parameter">hostname</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the IP host name or address on which the
|
||||
<command>postmaster</command> is to listen for TCP/IP
|
||||
connections from client applications. The value can also be a
|
||||
comma-separated list of addresses, or <literal>*</> to specify
|
||||
listening on all available interfaces. An empty value
|
||||
specifies not listening on any IP addresses, in which case
|
||||
only Unix-domain sockets can be used to connect to the
|
||||
<command>postmaster</command>. Defaults to listening only on
|
||||
<systemitem class="systemname">localhost</systemitem>.
|
||||
Specifying this option is equivalent to setting the <xref
|
||||
linkend="guc-listen-addresses"> configuration parameter.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-i</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Allows remote clients to connect via TCP/IP (Internet domain)
|
||||
connections. Without this option, only local connections are
|
||||
accepted. This option is equivalent to setting
|
||||
<varname>listen_addresses</> to <literal>*</> in
|
||||
<filename>postgresql.conf</> or via <option>-h</>.
|
||||
</para>
|
||||
<para>
|
||||
This option is deprecated since it does not allow access to the
|
||||
full functionality of <xref linkend="guc-listen-addresses">.
|
||||
It's usually better to set <varname>listen_addresses</> directly.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-k <replaceable class="parameter">directory</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the directory of the Unix-domain socket on which the
|
||||
<command>postmaster</command> is to listen for
|
||||
connections from client applications. The default is normally
|
||||
<filename>/tmp</filename>, but can be changed at build time.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-l</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Enables secure connections using <acronym>SSL</acronym>.
|
||||
<productname>PostgreSQL</productname> must have been compiled with
|
||||
support for <acronym>SSL</acronym> for this option to be
|
||||
available. For more information on using <acronym>SSL</acronym>,
|
||||
refer to <xref linkend="ssl-tcp">.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-N <replaceable class="parameter">max-connections</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Sets the maximum number of client connections that this
|
||||
<command>postmaster</command> will accept. By
|
||||
default, this value is 32, but it can be set as high as your
|
||||
system will support. (Note that
|
||||
<option>-B</option> is required to be at least twice
|
||||
<option>-N</option>. See <xref linkend="kernel-resources"> for a discussion of
|
||||
system resource requirements for large numbers of client
|
||||
connections.) Specifying this option is equivalent to setting the
|
||||
<xref linkend="guc-max-connections"> configuration parameter.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-o <replaceable class="parameter">extra-options</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The command line-style options specified in <replaceable
|
||||
class="parameter">extra-options</replaceable> are passed to
|
||||
all server processes started by this
|
||||
<command>postmaster</command>. See <xref
|
||||
linkend="app-postgres"> for possibilities. If the option
|
||||
string contains any spaces, the entire string must be quoted.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The use of this option is obsolete; all command-line options
|
||||
for server processes can be specified directly on the
|
||||
<command>postmaster</command> command line
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-p <replaceable class="parameter">port</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the TCP/IP port or local Unix domain socket file
|
||||
extension on which the <command>postmaster</command>
|
||||
is to listen for connections from client applications.
|
||||
Defaults to the value of the <envar>PGPORT</envar> environment
|
||||
variable, or if <envar>PGPORT</envar> is not set, then
|
||||
defaults to the value established during compilation (normally
|
||||
5432). If you specify a port other than the default port,
|
||||
then all client applications must specify the same port using
|
||||
either command-line options or <envar>PGPORT</envar>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-s</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Print time information and other statistics at the end of each command.
|
||||
This is useful for benchmarking or for use in tuning the number of
|
||||
buffers.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-S</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies that the <command>postmaster</command>
|
||||
process should start up in silent mode. That is, it will
|
||||
disassociate from the user's (controlling) terminal, start its
|
||||
own process group, and redirect its standard output and
|
||||
standard error to <filename>/dev/null</filename>.
|
||||
</para>
|
||||
<para>
|
||||
Using this switch discards all logging output, which is
|
||||
probably not what you want, since it makes it very difficult
|
||||
to troubleshoot problems. See below for a better way to start
|
||||
the <command>postmaster</command> in the background.
|
||||
</para>
|
||||
<para>
|
||||
<option>--silent-mode=false</option> has the opposite effect
|
||||
of this option.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>--<replaceable>name</replaceable>=<replaceable>value</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Sets a named run-time parameter; a shorter form of
|
||||
<option>-c</>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
</refsect2>
|
||||
|
||||
<refsect2>
|
||||
<title>Semi-internal Options</title>
|
||||
|
||||
<para>
|
||||
There are several other options that may be specified, 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. These are listed
|
||||
here only for the use by <productname>PostgreSQL</productname>
|
||||
system developers. <emphasis>Use of any of these options is
|
||||
highly discouraged.</emphasis> Furthermore, any of these options
|
||||
may disappear or change in a future release without notice.
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><option>-f</option> <literal>{ s | i | m | n | h }</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Forbids the use of particular scan and join methods:
|
||||
<literal>s</literal> and <literal>i</literal>
|
||||
disable sequential and index scans respectively, while
|
||||
<literal>n</literal>, <literal>m</literal>, and <literal>h</literal>
|
||||
disable nested-loop, merge and hash joins respectively.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Neither sequential scans nor nested-loop joins can be disabled
|
||||
completely; the <literal>-fs</literal> and
|
||||
<literal>-fn</literal> options simply discourage the optimizer
|
||||
from using those plan types if it has any other alternative.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-n</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This option is for debugging problems that cause a server
|
||||
process to die abnormally. The ordinary strategy in this
|
||||
situation is to notify all other server processes that they
|
||||
must terminate and then reinitialize the shared memory and
|
||||
semaphores. This is because an errant server process could
|
||||
have corrupted some shared state before terminating. This
|
||||
option specifies that the <command>postmaster</command> will
|
||||
not reinitialize shared data structures. A knowledgeable
|
||||
system programmer can then use a debugger to examine shared
|
||||
memory and semaphore state.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-O</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Allows the structure of system tables to be modified. This is
|
||||
used by <command>initdb</command>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-P</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Ignore system indexes when reading system tables (but still update
|
||||
the indexes when modifying the tables). This is useful when
|
||||
recovering from damaged system indexes.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-t</option> <literal>pa[rser] | pl[anner] | e[xecutor]</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Print timing statistics for each query relating to each of the
|
||||
major system modules. This option cannot be used together
|
||||
with the <option>-s</option> option.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-T</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This option is for debugging problems that cause a server
|
||||
process to die abnormally. The ordinary strategy in this
|
||||
situation is to notify all other server processes that they
|
||||
must terminate and then reinitialize the shared memory and
|
||||
semaphores. This is because an errant server process could
|
||||
have corrupted some shared state before terminating. This
|
||||
option specifies that the <command>postmaster</command> will
|
||||
stop all other server processes by sending the signal
|
||||
<literal>SIGSTOP</literal>, but will not cause them to
|
||||
terminate. This permits system programmers to collect core
|
||||
dumps from all server processes by hand.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-W</option> <replaceable class="parameter">seconds</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
A delay of this many seconds occurs when a new server process
|
||||
is started, after it conducts the authentication procedure.
|
||||
This is intended to give an opportunity to attach to the
|
||||
server process with a debugger.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect2>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Environment</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><envar>PGCLIENTENCODING</envar></term>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Default character encoding used by clients. (The clients may
|
||||
override this individually.) This value can also be set in the
|
||||
configuration file.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>PGDATA</envar></term>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Default data directory location
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>PGDATESTYLE</envar></term>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Default value of the <xref linkend="guc-datestyle"> run-time
|
||||
parameter. (The use of this environment variable is deprecated.)
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>PGPORT</envar></term>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Default port (preferably set in the configuration file)
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>TZ</envar></term>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Server time zone
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Diagnostics</title>
|
||||
|
||||
<para>
|
||||
A failure message mentioning <literal>semget</> or <literal>shmget</>
|
||||
probably indicates you need to configure your kernel to provide adequate
|
||||
shared memory and semaphores. For more discussion see <xref
|
||||
linkend="kernel-resources">.
|
||||
</para>
|
||||
|
||||
<tip>
|
||||
<para>
|
||||
You may be able to postpone reconfiguring your kernel by
|
||||
decreasing <xref linkend="guc-shared-buffers"> to reduce the
|
||||
shared memory consumption of <productname>PostgreSQL</>, and/or
|
||||
by reducing <xref linkend="guc-max-connections"> to reduce the
|
||||
semaphore consumption.
|
||||
</para>
|
||||
</tip>
|
||||
|
||||
<para>
|
||||
A failure message suggesting that another postmaster is already running
|
||||
should be checked carefully, for example by using the command
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>ps ax | grep postmaster</userinput>
|
||||
</screen>
|
||||
or
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>ps -ef | grep postmaster</userinput>
|
||||
</screen>
|
||||
depending on your system. If you are certain that no conflicting
|
||||
postmaster is running, you may remove the lock file mentioned in the
|
||||
message and try again.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A failure message indicating inability to bind to a port may
|
||||
indicate that that port is already in use by some
|
||||
non-<productname>PostgreSQL</productname> process. You may also
|
||||
get this error if you terminate the <command>postmaster</command>
|
||||
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 may 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 <quote>trusted</quote> and only permit
|
||||
the Unix superuser to access them.
|
||||
</para>
|
||||
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Notes</title>
|
||||
|
||||
<para>
|
||||
If at all possible, <emphasis>do not</emphasis> use
|
||||
<literal>SIGKILL</literal> to kill the
|
||||
<command>postmaster</command>. Doing so will prevent
|
||||
<command>postmaster</command> from freeing the system
|
||||
resources (e.g., shared memory and semaphores) that it holds before
|
||||
terminating. This may cause problems for starting a fresh
|
||||
<command>postmaster</command> run.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To terminate the <command>postmaster</command> normally,
|
||||
the signals <literal>SIGTERM</literal>, <literal>SIGINT</literal>,
|
||||
or <literal>SIGQUIT</literal> 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 <literal>SIGHUP</literal> signal will
|
||||
reload the server configuration files.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The utility command <xref linkend="app-pg-ctl"> can be used to
|
||||
start and shut down the <command>postmaster</command>
|
||||
safely and comfortably.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <option>--</> options will not work on <systemitem
|
||||
class="osname">FreeBSD</> or <systemitem class="osname">OpenBSD</>.
|
||||
Use <option>-c</> instead. This is a bug in the affected operating
|
||||
systems; a future release of <productname>PostgreSQL</productname>
|
||||
will provide a workaround if this is not fixed.
|
||||
</para>
|
||||
|
||||
</refsect1>
|
||||
|
||||
<refsect1 id="app-postmaster-examples">
|
||||
<title>Examples</title>
|
||||
<para>
|
||||
To start <command>postmaster</command> in the background
|
||||
using default values, type:
|
||||
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>nohup postmaster >logfile 2>&1 </dev/null &</userinput>
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To start <command>postmaster</command> with a specific
|
||||
port:
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>postmaster -p 1234</userinput>
|
||||
</screen>
|
||||
This command will start up <command>postmaster</command>
|
||||
communicating through the port 1234. In order to connect to this
|
||||
<command>postmaster</command> using <application>psql</>, you would need to
|
||||
run it as
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>psql -p 1234</userinput>
|
||||
</screen>
|
||||
or set the environment variable <envar>PGPORT</envar>:
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>export PGPORT=1234</userinput>
|
||||
<prompt>$</prompt> <userinput>psql</userinput>
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Named run-time parameters can be set in either of these styles:
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>postmaster -c work_mem=1234</userinput>
|
||||
<prompt>$</prompt> <userinput>postmaster --work-mem=1234</userinput>
|
||||
</screen>
|
||||
Either form overrides whatever setting might exist for <varname>work_mem</>
|
||||
in <filename>postgresql.conf</>. Notice that underscores in parameter
|
||||
names can be written as either underscore or dash on the command line.
|
||||
</para>
|
||||
|
||||
<tip>
|
||||
<para>
|
||||
Except for short-term experiments,
|
||||
it's probably better practice to edit the setting in
|
||||
<filename>postgresql.conf</> than to rely on a command-line switch
|
||||
to set a parameter.
|
||||
</para>
|
||||
</tip>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>See Also</title>
|
||||
|
||||
<para>
|
||||
<xref linkend="app-initdb">,
|
||||
<xref linkend="app-pg-ctl">
|
||||
<xref linkend="app-postgres">
|
||||
</para>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
||||
<!-- Keep this comment at the end of the file
|
||||
Local variables:
|
||||
mode: sgml
|
||||
sgml-omittag:nil
|
||||
sgml-shorttag:t
|
||||
sgml-minimize-attributes:nil
|
||||
sgml-always-quote-attributes:t
|
||||
sgml-indent-step:1
|
||||
sgml-indent-data:t
|
||||
sgml-parent-document:nil
|
||||
sgml-default-dtd-file:"../reference.ced"
|
||||
sgml-exposed-tags:nil
|
||||
sgml-local-catalogs:"/usr/lib/sgml/catalog"
|
||||
sgml-local-ecat-files:nil
|
||||
End:
|
||||
-->
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/reindex.sgml,v 1.29 2005/09/12 16:43:29 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/reindex.sgml,v 1.30 2006/06/18 15:38:36 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -148,7 +148,7 @@ REINDEX { INDEX | TABLE | DATABASE | SYSTEM } <replaceable class="PARAMETER">nam
|
||||
</para>
|
||||
|
||||
<para>
|
||||
One way to do this is to shut down the postmaster and start a stand-alone
|
||||
One way to do this is to shut down the server and start a single-user
|
||||
<productname>PostgreSQL</productname> server
|
||||
with the <option>-P</option> option included on its command line.
|
||||
Then, <command>REINDEX DATABASE</>, <command>REINDEX SYSTEM</>,
|
||||
@ -156,9 +156,9 @@ REINDEX { INDEX | TABLE | DATABASE | SYSTEM } <replaceable class="PARAMETER">nam
|
||||
issued, depending on how much you want to reconstruct. If in
|
||||
doubt, use <command>REINDEX SYSTEM</> to select
|
||||
reconstruction of all system indexes in the database. Then quit
|
||||
the standalone server session and restart the regular server.
|
||||
the single-user server session and restart the regular server.
|
||||
See the <xref linkend="app-postgres"> reference page for more
|
||||
information about how to interact with the stand-alone server
|
||||
information about how to interact with the single-user server
|
||||
interface.
|
||||
</para>
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/show.sgml,v 1.39 2005/06/14 20:42:52 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/show.sgml,v 1.40 2006/06/18 15:38:36 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -36,7 +36,7 @@ SHOW ALL
|
||||
the <envar>PGOPTIONS</envar> environmental variable (when using
|
||||
<application>libpq</> or a <application>libpq</>-based
|
||||
application), or through command-line flags when starting the
|
||||
<command>postmaster</command>. See <xref
|
||||
<command>postgres</command>. See <xref
|
||||
linkend="runtime-config"> for details.
|
||||
</para>
|
||||
</refsect1>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/regress.sgml,v 1.51 2006/04/06 18:54:36 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/regress.sgml,v 1.52 2006/06/18 15:38:36 petere Exp $ -->
|
||||
|
||||
<chapter id="regress">
|
||||
<title id="regress-title">Regression Tests</title>
|
||||
@ -316,7 +316,7 @@ exclusion of those that don't.
|
||||
<![%standalone-ignore;[<xref linkend="guc-max-stack-depth">]]>
|
||||
<![%standalone-include;[<literal>max_stack_depth</literal>]]>
|
||||
parameter indicates. This
|
||||
can be fixed by running the postmaster under a higher stack
|
||||
can be fixed by running the server under a higher stack
|
||||
size limit (4MB is recommended with the default value of
|
||||
<varname>max_stack_depth</>). If you are unable to do that, an
|
||||
alternative is to reduce the value of <varname>max_stack_depth</>.
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.371 2006/04/27 02:29:14 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.372 2006/06/18 15:38:36 petere Exp $ -->
|
||||
|
||||
<chapter Id="runtime">
|
||||
<title>Operating System Environment</title>
|
||||
@ -161,19 +161,19 @@ postgres$ <userinput>initdb -D /usr/local/pgsql/data</userinput>
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="postmaster-start">
|
||||
<sect1 id="server-start">
|
||||
<title>Starting the Database Server</title>
|
||||
|
||||
<para>
|
||||
Before anyone can access the database, you must start the database
|
||||
server. The database server program is called
|
||||
<command>postmaster</command>.<indexterm><primary>postmaster</></>
|
||||
The <command>postmaster</command> must know where to
|
||||
<command>postgres</command>.<indexterm><primary>postgres</></>
|
||||
The <command>postgres</command> program must know where to
|
||||
find the data it is supposed to use. This is done with the
|
||||
<option>-D</option> option. Thus, the simplest way to start the
|
||||
server is:
|
||||
<screen>
|
||||
$ <userinput>postmaster -D /usr/local/pgsql/data</userinput>
|
||||
$ <userinput>postgres -D /usr/local/pgsql/data</userinput>
|
||||
</screen>
|
||||
which will leave the server running in the foreground. This must be
|
||||
done while logged into the <productname>PostgreSQL</productname> user
|
||||
@ -183,10 +183,10 @@ $ <userinput>postmaster -D /usr/local/pgsql/data</userinput>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Normally it is better to start the <command>postmaster</command> in the
|
||||
Normally it is better to start <command>postgres</command> in the
|
||||
background. For this, use the usual shell syntax:
|
||||
<screen>
|
||||
$ <userinput>postmaster -D /usr/local/pgsql/data >logfile 2>&1 &</userinput>
|
||||
$ <userinput>postgres -D /usr/local/pgsql/data >logfile 2>&1 &</userinput>
|
||||
</screen>
|
||||
It is important to store the server's <systemitem>stdout</> and
|
||||
<systemitem>stderr</> output somewhere, as shown above. It will help
|
||||
@ -196,9 +196,9 @@ $ <userinput>postmaster -D /usr/local/pgsql/data >logfile 2>&1 &</
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <command>postmaster</command> also takes a number of other
|
||||
command line options. For more information, see the
|
||||
<xref linkend="app-postmaster"> reference page
|
||||
The <command>postgres</command> program also takes a number of other
|
||||
command-line options. For more information, see the
|
||||
<xref linkend="app-postgres"> reference page
|
||||
and <xref linkend="runtime-config"> below.
|
||||
</para>
|
||||
|
||||
@ -212,7 +212,7 @@ pg_ctl start -l logfile
|
||||
</programlisting>
|
||||
will start the server in the background and put the output into the
|
||||
named log file. The <option>-D</option> option has the same meaning
|
||||
here as in the <command>postmaster</command>. <command>pg_ctl</command>
|
||||
here as for <command>postgres</command>. <command>pg_ctl</command>
|
||||
is also capable of stopping the server.
|
||||
</para>
|
||||
|
||||
@ -262,7 +262,7 @@ su -c 'pg_ctl start -D /usr/local/pgsql/data -l serverlog' postgres
|
||||
to the file <filename>/etc/rc.local</filename>:
|
||||
<indexterm><primary>OpenBSD</><secondary>start script</secondary></>
|
||||
<programlisting>
|
||||
if [ -x /usr/local/pgsql/bin/pg_ctl -a -x /usr/local/pgsql/bin/postmaster ]; then
|
||||
if [ -x /usr/local/pgsql/bin/pg_ctl -a -x /usr/local/pgsql/bin/postgres ]; then
|
||||
su - -c '/usr/local/pgsql/bin/pg_ctl start -l /var/postgresql/log -s' postgres
|
||||
echo -n ' postgresql'
|
||||
fi
|
||||
@ -310,15 +310,15 @@ su - postgres -c "/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgs
|
||||
</para>
|
||||
|
||||
<para>
|
||||
While the <command>postmaster</command> is running, its
|
||||
While the server is running, its
|
||||
<acronym>PID</acronym> is stored in the file
|
||||
<filename>postmaster.pid</filename> in the data directory. This is
|
||||
used to prevent multiple <command>postmaster</command> processes
|
||||
used to prevent multiple server instances from
|
||||
running in the same data directory and can also be used for
|
||||
shutting down the <command>postmaster</command> process.
|
||||
shutting down the server.
|
||||
</para>
|
||||
|
||||
<sect2 id="postmaster-start-failures">
|
||||
<sect2 id="server-start-failures">
|
||||
<title>Server Start-up Failures</title>
|
||||
|
||||
<para>
|
||||
@ -336,13 +336,13 @@ HINT: Is another postmaster already running on port 5432? If not, wait a few se
|
||||
FATAL: could not create TCP/IP listen socket
|
||||
</screen>
|
||||
This usually means just what it suggests: you tried to start
|
||||
another <command>postmaster</command> on the same port where one is already running.
|
||||
another server on the same port where one is already running.
|
||||
However, if the kernel error message is not <computeroutput>Address
|
||||
already in use</computeroutput> or some variant of that, there may
|
||||
be a different problem. For example, trying to start a <command>postmaster</command>
|
||||
be a different problem. For example, trying to start a server
|
||||
on a reserved port number may draw something like:
|
||||
<screen>
|
||||
$ <userinput>postmaster -p 666</userinput>
|
||||
$ <userinput>postgres -p 666</userinput>
|
||||
LOG: could not bind IPv4 socket: Permission denied
|
||||
HINT: Is another postmaster already running on port 666? If not, wait a few seconds and retry.
|
||||
FATAL: could not create TCP/IP listen socket
|
||||
@ -495,7 +495,7 @@ psql: could not connect to server: No such file or directory
|
||||
<acronym>IPC</> limits, the server will refuse to start and
|
||||
should leave an instructive error message describing the problem
|
||||
encountered and what to do about it. (See also <xref
|
||||
linkend="postmaster-start-failures">.) The relevant kernel
|
||||
linkend="server-start-failures">.) The relevant kernel
|
||||
parameters are named consistently across different systems; <xref
|
||||
linkend="sysvipc-parameters"> gives an overview. The methods to set
|
||||
them, however, vary. Suggestions for some platforms are given below.
|
||||
@ -1181,7 +1181,7 @@ default:\
|
||||
optimal for <productname>PostgreSQL</productname>. Because of the
|
||||
way that the kernel implements memory overcommit, the kernel may
|
||||
terminate the <productname>PostgreSQL</productname> server (the
|
||||
<filename>postmaster</filename> process) if the memory demands of
|
||||
master server process) if the memory demands of
|
||||
another process cause the system to run out of virtual memory.
|
||||
</para>
|
||||
|
||||
@ -1190,9 +1190,9 @@ default:\
|
||||
this (consult your system documentation and configuration on where
|
||||
to look for such a message):
|
||||
<programlisting>
|
||||
Out of Memory: Killed process 12345 (postmaster).
|
||||
Out of Memory: Killed process 12345 (postgres).
|
||||
</programlisting>
|
||||
This indicates that the <filename>postmaster</filename> process
|
||||
This indicates that the <filename>postgres</filename> process
|
||||
has been terminated due to memory pressure.
|
||||
Although existing database connections will continue to function
|
||||
normally, no new connections will be accepted. To recover,
|
||||
@ -1237,17 +1237,17 @@ sysctl -w vm.overcommit_memory=2
|
||||
</sect1>
|
||||
|
||||
|
||||
<sect1 id="postmaster-shutdown">
|
||||
<sect1 id="server-shutdown">
|
||||
<title>Shutting Down the Server</title>
|
||||
|
||||
<indexterm zone="postmaster-shutdown">
|
||||
<indexterm zone="server-shutdown">
|
||||
<primary>shutdown</>
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
There are several ways to shut down the database server. You control
|
||||
the type of shutdown by sending different signals to the
|
||||
<command>postmaster</command> process.
|
||||
the type of shutdown by sending different signals to the master
|
||||
<command>postgres</command> process.
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
@ -1281,7 +1281,7 @@ sysctl -w vm.overcommit_memory=2
|
||||
<listitem>
|
||||
<para>
|
||||
This is the <firstterm>Immediate Shutdown</firstterm>, which
|
||||
will cause the <command>postmaster</command> process to send a
|
||||
will cause the master <command>postgres</command> process to send a
|
||||
<systemitem>SIGQUIT</systemitem> to all child processes and exit
|
||||
immediately, without properly shutting itself down. The child processes
|
||||
likewise exit immediately upon receiving
|
||||
@ -1301,7 +1301,7 @@ sysctl -w vm.overcommit_memory=2
|
||||
|
||||
<para>
|
||||
Alternatively, you can send the signal directly using <command>kill</>.
|
||||
The <acronym>PID</> of the <command>postmaster</command> process can be
|
||||
The <acronym>PID</> of the <command>postgres</command> process can be
|
||||
found using the <command>ps</command> program, or from the file
|
||||
<filename>postmaster.pid</filename> in the data directory. For
|
||||
example, to do a fast shutdown:
|
||||
@ -1316,7 +1316,7 @@ $ <userinput>kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`</userinput
|
||||
the server. Doing so will prevent the server from releasing
|
||||
shared memory and semaphores, which may then have to be done
|
||||
manually before a new server can be started. Furthermore,
|
||||
<systemitem>SIGKILL</systemitem> kills the <command>postmaster</command>
|
||||
<systemitem>SIGKILL</systemitem> kills the <command>postgres</command>
|
||||
process without letting it relay the signal to its subprocesses,
|
||||
so it will be necessary to kill the individual subprocesses by hand as
|
||||
well.
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/start.sgml,v 1.40 2006/03/10 19:10:49 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/start.sgml,v 1.41 2006/06/18 15:38:36 petere Exp $ -->
|
||||
|
||||
<chapter id="tutorial-start">
|
||||
<title>Getting Started</title>
|
||||
@ -76,8 +76,8 @@
|
||||
connections to the database from client applications, and
|
||||
performs actions on the database on behalf of the clients. The
|
||||
database server program is called
|
||||
<filename>postmaster</filename>.
|
||||
<indexterm><primary>postmaster</primary></indexterm>
|
||||
<filename>postgres</filename>.
|
||||
<indexterm><primary>postgres</primary></indexterm>
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -112,8 +112,8 @@
|
||||
starts (<quote>forks</quote>) a new process for each connection.
|
||||
From that point on, the client and the new server process
|
||||
communicate without intervention by the original
|
||||
<filename>postmaster</filename> process. Thus, the
|
||||
<filename>postmaster</filename> is always running, waiting for
|
||||
<filename>postgres</filename> process. Thus, the
|
||||
master server process is always running, waiting for
|
||||
client connections, whereas client and associated server processes
|
||||
come and go. (All of this is of course invisible to the user. We
|
||||
only mention it here for completeness.)
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/storage.sgml,v 1.10 2006/04/23 03:39:52 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/storage.sgml,v 1.11 2006/06/18 15:38:36 petere Exp $ -->
|
||||
|
||||
<chapter id="storage">
|
||||
|
||||
@ -23,7 +23,7 @@ All the data needed for a database cluster is stored within the cluster's data
|
||||
directory, commonly referred to as <varname>PGDATA</> (after the name of the
|
||||
environment variable that can be used to define it). A common location for
|
||||
<varname>PGDATA</> is <filename>/var/lib/pgsql/data</>. Multiple clusters,
|
||||
managed by different postmasters, can exist on the same machine.
|
||||
managed by different server instances, can exist on the same machine.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -99,14 +99,14 @@ Item
|
||||
|
||||
<row>
|
||||
<entry><filename>postmaster.opts</></entry>
|
||||
<entry>A file recording the command-line options the postmaster was
|
||||
<entry>A file recording the command-line options the server was
|
||||
last started with</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>postmaster.pid</></entry>
|
||||
<entry>A lock file recording the current postmaster PID and shared memory
|
||||
segment ID (not present after postmaster shutdown)</entry>
|
||||
<entry>A lock file recording the current server PID and shared memory
|
||||
segment ID (not present after server shutdown)</entry>
|
||||
</row>
|
||||
|
||||
</tbody>
|
||||
|
Reference in New Issue
Block a user