runtime.sgml

PostgreSQL7.4.6 for Linux

        The default permissions are <literal>0777</literal>, meaning
        anyone can connect. Reasonable alternatives are
        <literal>0770</literal> (only user and group, see also under
        <varname>unix_socket_group</varname>) and <literal>0700</literal>
        (only user). (Note that actually for a Unix domain socket, only write
        permission matters and there is no point in setting or revoking
        read or execute permissions.)
       </para>

       <para>
        This access control mechanism is independent of the one
        described in <xref linkend="client-authentication">.
       </para>

       <para>
        This option can only be set at server start.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><varname>virtual_host</varname> (<type>string</type>)</term>
      <listitem>
       <para>
        Specifies the host name or IP address on which the server is
        to listen for connections from client applications. The
        default is to listen on all configured addresses (including
        <systemitem class="systemname">localhost</>).
       </para>
      </listitem>
     </varlistentry>
     
     <varlistentry>
      <term><varname>rendezvous_name</varname> (<type>string</type>)</term>
      <listitem>
       <para>
        Specifies the Rendezvous broadcast name.  By default, the
        computer name is used, specified as ''.
       </para>
      </listitem>
     </varlistentry>
     
     </variablelist>
     </sect3>
     <sect3 id="runtime-config-connection-security">
     <title>Security and Authentication</title>
     
     <variablelist>
     <varlistentry>
      <term><varname>authentication_timeout</varname> (<type>integer</type>)</term>
      <indexterm><primary>timeout</><secondary>client authentication</></indexterm>
      <indexterm><primary>client authentication</><secondary>timeout during</></indexterm>
      <listitem>
       <para>
        Maximum time to complete client authentication, in seconds. If a
        would-be client has not completed the authentication protocol in
        this much time, the server breaks the connection. This prevents
        hung clients from occupying a connection indefinitely. This
        option can only be set at server start or in the
        <filename>postgresql.conf</filename> file. The default is 60.
       </para>
      </listitem>
     </varlistentry>
     
     <varlistentry>
      <indexterm>
       <primary>SSL</primary>
      </indexterm>

      <term><varname>ssl</varname> (<type>boolean</type>)</term>
      <listitem>
       <para>
        Enables <acronym>SSL</> connections. Please read
        <xref linkend="ssl-tcp"> before using this. The default
        is off.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><varname>password_encryption</varname> (<type>boolean</type>)</term>
      <listitem>
       <para>
        When a password is specified in <command>CREATE USER</> or
        <command>ALTER USER</> without writing either <literal>ENCRYPTED</> or
        <literal>UNENCRYPTED</>, this option determines whether the password is to be
        encrypted. The default is on (encrypt the password).
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><varname>krb_server_keyfile</varname> (<type>string</type>)</term>
      <listitem>
       <para>
        Sets the location of the Kerberos server key file. See
        <xref linkend="kerberos-auth"> for details.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><varname>db_user_namespace</varname> (<type>boolean</type>)</term>
      <listitem>
       <para>
        This allows per-database user names.  It is off by default.
       </para>

       <para>
        If this is on, you should create users as <literal>username@dbname</>.
        When <literal>username</> is passed by a connecting client,
        <literal>@</> and the database name is appended to the user
        name and that database-specific user name is looked up by the
        server. Note that when you create users with names containing
        <literal>@</> within the SQL environment, you will need to
        quote the user name.
       </para>

       <para>
        With this option enabled, you can still create ordinary global
        users.  Simply append <literal>@</> when specifying the user
        name in the client.  The <literal>@</> will be stripped off
        before the user name is looked up by the server.
       </para>

       <note>
        <para>
         This feature is intended as a temporary measure until a
         complete solution is found.  At that time, this option will
         be removed.
        </para>
       </note>
      </listitem>
     </varlistentry>

    </variablelist>
    </sect3>
   </sect2>

   <sect2 id="runtime-config-resource">
    <title>Resource Consumption</title>

    <sect3 id="runtime-config-resource-memory">
     <title>Memory</title>

     <variablelist>
     <varlistentry>
      <term><varname>shared_buffers</varname> (<type>integer</type>)</term>
      <listitem>
       <para>
        Sets the number of shared memory buffers used by the database
        server. The default is typically 1000, but may be less if your
        kernel settings will not support it (as determined during
        <application>initdb</>).  Each buffer is 8192 bytes, unless a
        different value of <literal>BLCKSZ</> was chosen when building
        the server.  This setting must be at least 16, as well as at
        least twice the value of <varname>max_connections</varname>;
        however, settings significantly higher than the minimum are
        usually needed for good performance.  Values of a few thousand
        are recommended for production installations.  This option can
        only be set at server start.
       </para>

       <para>
        Increasing this parameter may cause <productname>PostgreSQL</>
        to request more <systemitem class="osname">System V</> shared
        memory than your operating system's default configuration
        allows. See <xref linkend="sysvipc"> for information on how to
        adjust these parameters, if necessary.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><varname>sort_mem</varname> (<type>integer</type>)</term>
      <listitem>
       <para>
        Specifies the amount of memory to be used by internal sort operations and
        hash tables before switching to temporary disk files. The value is
        specified in kilobytes, and defaults to 1024 kilobytes (1 MB).
        Note that for a complex query, several sort or hash operations might be
        running in parallel; each one will be allowed to use as much memory
        as this value specifies before it starts to put data into temporary
        files. Also, several running sessions could be doing
        sort operations simultaneously.  So the total memory used could be many
        times the value of <varname>sort_mem</varname>. Sort operations are used
        by <literal>ORDER BY</>, merge joins, and <command>CREATE INDEX</>.
        Hash tables are used in hash joins, hash-based aggregation, and
        hash-based processing of <literal>IN</> subqueries.  Because 
        <command>CREATE INDEX</> is used when restoring a database,
        increasing <varname>sort_mem</varname> before doing a large
        restore operation can improve performance.
       </para>
      </listitem>
     </varlistentry>
     
     <varlistentry>
      <term><varname>vacuum_mem</varname> (<type>integer</type>)</term>
      <listitem>
       <para>
        Specifies the maximum amount of memory to be used by
        <command>VACUUM</command> to keep track of to-be-reclaimed
        rows. The value is specified in kilobytes, and defaults to
        8192 kB. Larger settings may improve the speed of
        vacuuming large tables that have many deleted rows.
       </para>
      </listitem>
     </varlistentry>

     </variablelist>
     </sect3>
     <sect3 id="runtime-config-resource-fsm">
     <title>Free Space Map</title>

     <variablelist>
     <varlistentry>
      <term><varname>max_fsm_pages</varname> (<type>integer</type>)</term>
      <listitem>
       <para>
        Sets the maximum number of disk pages for which free space will
        be tracked in the shared free-space map.  Six bytes of shared memory
        are consumed for each page slot.  This setting must be more than
        16 * <varname>max_fsm_relations</varname>.  The default is 20000.
        This option can only be set at server start.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><varname>max_fsm_relations</varname> (<type>integer</type>)</term>
      <listitem>
       <para>
        Sets the maximum number of relations (tables and indexes) for which
        free space will be tracked in the shared free-space map.  Roughly
        fifty bytes of shared memory are consumed for each slot.
        The default is 1000.
        This option can only be set at server start.
       </para>
      </listitem>
     </varlistentry>
     
     </variablelist>
     </sect3>
     <sect3 id="runtime-config-resource-kernel">
     <title>Kernel Resource Usage</title>
     <variablelist>

     <varlistentry>
      <term><varname>max_files_per_process</varname> (<type>integer</type>)</term>
      <listitem>
       <para>
        Sets the maximum number of simultaneously open files allowed to each
        server subprocess. The default is 1000. If the kernel is enforcing
        a safe per-process limit, you don't need to worry about this setting.
        But on some platforms (notably, most BSD systems), the kernel will
        allow individual processes to open many more files than the system
        can really support when a large number of processes all try to open
        that many files. If you find yourself seeing <quote>Too many open
        files</> failures, try reducing this setting.
        This option can only be set at server start.
       </para>
      </listitem>
     </varlistentry>
     
     <varlistentry>
      <term><varname>preload_libraries</varname> (<type>string</type>)</term>
      <indexterm><primary>preload_libraries</></>
      <listitem>
       <para>
        This variable specifies one or more shared libraries that are
        to be preloaded at server start. A parameterless
        initialization function can optionally be called for each
        library.  To specify that, add a colon and the name of the
        initialization function after the library name. For example
        <literal>'$libdir/mylib:mylib_init'</literal> would cause
        <literal>mylib</> to be preloaded and <literal>mylib_init</>
        to be executed. If more than one library is to be loaded,
        separate their names with commas.
       </para>

       <para>
        If <literal>mylib</> or <literal>mylib_init</> are not found, the
        server will fail to start.
       </para>

       <para>
        <productname>PostgreSQL</productname> procedural language
        libraries may be preloaded in this way, typically by using the
        syntax <literal>'$libdir/plXXX:plXXX_init'</literal> where
        <literal>XXX</literal> is <literal>pgsql</>, <literal>perl</>,
        <literal>tcl</>, or <literal>python</>.
       </para>

       <para>
        By preloading a shared library (and initializing it if
        applicable), the library startup time is avoided when the
        library is first used.  However, the time to start each new
        server process may increase, even if that process never
        uses the library.
       </para>
      </listitem>
     </varlistentry>

     </variablelist>
    </sect3>
   </sect2>

   <sect2 id="runtime-config-wal">
    <title>Write Ahead Log</title>

   <para>
    See also <xref linkend="wal-configuration"> for details on WAL
    tuning.
   </para>

    <sect3 id="runtime-config-wal-settings">
     <title>Settings</title>
     <variablelist>
     
     <varlistentry>
      <indexterm>
       <primary>fsync</primary>
      </indexterm>

      <term><varname>fsync</varname> (<type>boolean</type>)</term>
      <listitem>
       <para>
        If this option is on, the <productname>PostgreSQL</> server
        will use the <function>fsync()</> system call in several places
        to make sure that updates are physically written to disk. This
        insures that a database cluster will recover to a
        consistent state after an operating system or hardware crash.
        (Crashes of the database server itself are <emphasis>not</>
        related to this.)
       </para>

       <para>
        However, using <function>fsync()</function> results in a
        performance penalty: when a transaction is committed,