runtime.sgml

PostgreSQL7.4.6 for Linux

<!--
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.215.2.8 2004/04/22 08:31:36 petere Exp $
-->

<Chapter Id="runtime">
 <Title>Server Run-time Environment</Title>

 <Para>
  This chapter discusses how to set up and run the database server
  and the interactions with the operating system.
 </para>

 <sect1 id="postgres-user">
  <title>The <productname>PostgreSQL</productname> User Account</title>

  <indexterm>
   <primary>postgres user</primary>
  </indexterm>

  <para>
   As with any other server daemon that is connected to outside world,
   it is advisable to run <productname>PostgreSQL</productname> under a
   separate user account. This user account should only own the data
   that is managed by the server, and should not be shared with other
   daemons. (For example, using the user <literal>nobody</literal> is a bad
   idea.) It is not advisable to install executables owned by
   this user because compromised systems could then modify their own 
   binaries.
  </para>

  <para>
   To add a Unix user account to your system, look for a command
   <command>useradd</command> or <command>adduser</command>. The user
   name <systemitem>postgres</systemitem> is often used but is by no
   means required.
  </para>
 </sect1>

 <sect1 id="creating-cluster">
  <title>Creating a Database Cluster</title>

  <indexterm>
   <primary>database cluster</primary>
  </indexterm>

  <indexterm>
   <primary>data area</primary>
   <see>database cluster</see>
  </indexterm>

  <para>
   Before you can do anything, you must initialize a database storage
   area on disk. We call this a <firstterm>database cluster</firstterm>.
   (<acronym>SQL</acronym> uses the term catalog cluster instead.) A
   database cluster is a collection of databases is accessible by a
   single instance of a running database server. After initialization, a
   database cluster will contain a database named
   <literal>template1</literal>. As the name suggests, this will be used
   as a template for subsequently created databases; it should not be
   used for actual work.  (See <xref linkend="managing-databases"> for information
   about creating databases.)
  </para>

  <para>
   In file system terms, a database cluster will be a single directory
   under which all data will be stored. We call this the <firstterm>data
   directory</firstterm> or <firstterm>data area</firstterm>. It is
   completely up to you where you choose to store your data.  There is no
   default, although locations such as
   <filename>/usr/local/pgsql/data</filename> or
   <filename>/var/lib/pgsql/data</filename> are popular. To initialize a
   database cluster, use the command <command>initdb</command>,<indexterm><primary>initdb</></> which is
   installed with <productname>PostgreSQL</productname>. The desired
   file system location of your database system is indicated by the
   <option>-D</option> option, for example
<screen>
<prompt>$</> <userinput>initdb -D /usr/local/pgsql/data</userinput>
</screen>
   Note that you must execute this command while logged into the
   <productname>PostgreSQL</productname> user account, which is
   described in the previous section.
  </para>

  <tip>
   <para>
    As an alternative to the <option>-D</option> option, you can set
    the environment variable <envar>PGDATA</envar>.
    <indexterm><primary><envar>PGDATA</envar></primary></indexterm>
   </para>
  </tip>

  <para>
   <command>initdb</command> will attempt to create the directory you
   specify if it does not already exist. It is likely that it will not
   have the permission to do so (if you followed our advice and created
   an unprivileged account). In that case you should create the
   directory yourself (as root) and change the owner to be the
   <productname>PostgreSQL</productname> user. Here is how this might
   be done:
<screen>
root# <userinput>mkdir /usr/local/pgsql/data</userinput>
root# <userinput>chown postgres /usr/local/pgsql/data</userinput>
root# <userinput>su postgres</userinput>
postgres$ <userinput>initdb -D /usr/local/pgsql/data</userinput>
</screen>
  </para>

  <para>
   <command>initdb</command> will refuse to run if the data directory
   looks like it it has already been initialized.</para>

  <para>
   Because the data directory contains all the data stored in the
   database, it is essential that it be secured from unauthorized
   access. <command>initdb</command> therefore revokes access
   permissions from everyone but the
   <productname>PostgreSQL</productname> user.
  </para>

  <para>
   However, while the directory contents are secure, the default
   client authentication setup allows any local user to connect to the
   database and even become the database superuser. If you do not
   trust other local users, we recommend you use
   <command>initdb</command>'s <option>-W</option> or
   <option>--pwprompt</option> option to assign a password to the
   database superuser.<indexterm><primary>password</><secondary>of the
   superuser</></indexterm> After <command>initdb</command>, modify
   the <filename>pg_hba.conf</filename> file to use <literal>md5</> or
   <literal>password</> instead of <literal>trust</> authentication
   <emphasis>before</> you start the server for the first time. (Other
   approaches include using <literal>ident</literal> authentication or
   file system permissions to restrict connections. See <xref
   linkend="client-authentication"> for more information.)
  </para>

  <para>
   <command>initdb</command> also initializes the default
   locale<indexterm><primary>locale</></> for the database cluster.
   Normally, it will just take the locale settings in the environment
   and apply them to the initialized database.  It is possible to
   specify a different locale for the database; more information about
   that can be found in <xref linkend="locale">.  The sort order used
   within a particular database cluster is set by
   <command>initdb</command> and cannot be changed later, short of
   dumping all data, rerunning <command>initdb</command>, and
   reloading the data. So it's important to make this choice correctly
   the first time.
  </para>
 </sect1>

 <sect1 id="postmaster-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
   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>
</screen>
   which will leave the server running in the foreground. This must be
   done while logged into the <productname>PostgreSQL</productname> user
   account. Without <option>-D</option>, the server will try to use
   the data directory in the environment variable <envar>PGDATA</envar>.
   If neither of these succeed, it will fail.
  </para>

  <para>
   To start the <command>postmaster</command> in the
   background, use the usual shell syntax:
<screen>
$ <userinput>postmaster -D /usr/local/pgsql/data &gt;logfile 2&gt;&amp;1 &amp;</userinput>
</screen>
   It is an important to store the server's <systemitem>stdout</> and
   <systemitem>stderr</> output somewhere, as shown above. It will help
   for auditing purposes and to diagnose problems. (See <xref
   linkend="logfile-maintenance"> for a more thorough discussion of log
   file handling.)
  </para>

  <para>
   The <command>postmaster</command> also takes a number of other
   command line options. For more information, see the reference page
   and <xref linkend="runtime-config"> below. In particular, in order
   for the server to accept
   TCP/IP<indexterm><primary>TCP/IP</primary></indexterm> connections
   (rather than just Unix-domain socket ones), you must specify the
   <option>-i</option> option.
  </para>

  <para>
   This shell syntax can get tedious quickly.  Therefore the shell
   script wrapper
   <command>pg_ctl</command><indexterm><primary>pg_ctl</primary></indexterm>
   is provided to simplify some tasks.  For example:
<programlisting>
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> is also
   capable of stopping the server.
  </para>

  <para>
   Normally, you will want to start the database server when the
   computer boots.<indexterm><primary>booting</><secondary>starting
   the server during</></> Autostart scripts are operating
   system-specific.  There are a few distributed with
   <productname>PostgreSQL</productname> in the
   <filename>contrib/start-scripts</> directory. This may require root
   privileges.
  </para>

  <para>
   Different systems have different conventions for starting up daemons
   at boot time. Many systems have a file
   <filename>/etc/rc.local</filename> or
   <filename>/etc/rc.d/rc.local</filename>. Others use
   <filename>rc.d</> directories. Whatever you do, the server must be
   run by the <productname>PostgreSQL</productname> user account
   <emphasis>and not by root</emphasis> or any other user. Therefore you
   probably should form your commands using <literal>su -c '...'
   postgres</literal>.  For example:
<programlisting>
su -c 'pg_ctl start -D /usr/local/pgsql/data -l serverlog' postgres
</programlisting>
  </para>

  <para>
   Here are a few more operating system specific suggestions. (Always
   replace these with the proper installation directory and the user
   name.)

   <itemizedlist>
    <listitem>
     <para>
      For <productname>FreeBSD</productname>, look at the file
      <filename>contrib/start-scripts/freebsd</filename> in the
      <productname>PostgreSQL</productname> source distribution.
      <indexterm><primary>FreeBSD</><secondary>start script</secondary></>
     </para>
    </listitem>

    <listitem>
     <para>
      On <productname>OpenBSD</productname>, add the following lines
      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
    su - -c '/usr/local/pgsql/bin/pg_ctl start -l /var/postgresql/log -s' postgres
    echo -n ' postgresql'
fi
</programlisting>
     </para>
    </listitem>

    <listitem>
     <para>
      On <productname>Linux</productname> systems either add
      <indexterm><primary>Linux</><secondary>start script</secondary></>
<programlisting>
/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data
</programlisting>
      to <filename>/etc/rc.d/rc.local</filename> or look at the file
      <filename>contrib/start-scripts/linux</filename> in the
      <productname>PostgreSQL</productname> source distribution.
     </para>
    </listitem>

    <listitem>
     <para>
      On <productname>NetBSD</productname>, either use the
      <productname>FreeBSD</productname> or
      <productname>Linux</productname> start scripts, depending on
      preference. <indexterm><primary>NetBSD</><secondary>start script</secondary></>
     </para>
    </listitem>

    <listitem>
     <para>
      On <productname>Solaris</productname>, create a file called
      <filename>/etc/init.d/postgresql</filename> that contains
      the following line:
      <indexterm><primary>Solaris</><secondary>start script</secondary></>
<programlisting>
su - postgres -c "/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data"
</programlisting>
      Then, create a symbolic link to it in <filename>/etc/rc3.d</> as
      <filename>S99postgresql</>.
     </para>
    </listitem>
   </itemizedlist>

  </para>

   <para>
    While the <command>postmaster</command> 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
    running in the same data directory and can also be used for
    shutting down the <command>postmaster</command> process.
   </para>

   <sect2 id="postmaster-start-failures">
    <title>Server Start-up Failures</title>

    <para>
     There are several common reasons the server might fail to
     start. Check the server's log file, or start it by hand (without
     redirecting standard output or standard error) and see what error
     messages appear. Below we explain some of the most common error
     messages in more detail.
    </para>

    <para>
<screen>
LOG:  could not bind IPv4 socket: Address already in use
HINT:  Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
FATAL:  could not create 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.
     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>
     on a reserved port number may draw something like:
<screen>
$ <userinput>postmaster -i -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