config.sgml

来自「PostgreSQL 8.1.4的源码 适用于Linux下的开源数据库系统」· SGML 代码 · 共 1,536 行 · 第 1/5 页

     </varlistentry>

     <varlistentry id="guc-db-user-namespace" xreflabel="db_user_namespace">
      <term><varname>db_user_namespace</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>db_user_namespace</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        This enables 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 are 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>
    </sect2>
   </sect1>

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

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

     <variablelist>
     <varlistentry id="guc-shared-buffers" xreflabel="shared_buffers">
      <term><varname>shared_buffers</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>shared_buffers</> configuration parameter</primary>
      </indexterm>
      <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 <symbol>BLCKSZ</symbol> was chosen when building
        the server.  This setting must be at least 16, as well as at
        least twice the value of <xref linkend="guc-max-connections">;
        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 those parameters, if necessary.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-temp-buffers" xreflabel="temp_buffers">
      <term><varname>temp_buffers</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>temp_buffers</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Sets the maximum number of temporary buffers used by each database
        session.  These are session-local buffers used only for access
        to temporary tables.  The default is 1000.  The setting can
        be changed within individual sessions, but only up until the
        first use of temporary tables within a session; subsequent
        attempts to change the value will have no effect on that session.
       </para>

       <para>
        A session will allocate temporary buffers as needed up to the limit
        given by <varname>temp_buffers</>.  The cost of setting a large
        value in sessions that do not actually need a lot of temporary
        buffers is only a buffer descriptor, or about 64 bytes, per
        increment in <varname>temp_buffers</>.  However if a buffer is
        actually used an additional 8192 bytes will be consumed for it
        (or in general, <symbol>BLCKSZ</symbol> bytes).
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-max-prepared-transactions" xreflabel="max_prepared_transactions">
      <term><varname>max_prepared_transactions</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>max_prepared_transactions</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Sets the maximum number of transactions that can be in the
        <quote>prepared</> state simultaneously (see <xref
        linkend="sql-prepare-transaction"
        endterm="sql-prepare-transaction-title">).
        Setting this parameter to zero disables the prepared-transaction
        feature.
        The default is 5.
        This option can only be set at server start.
       </para>

       <para>
        If you are not using prepared transactions, this parameter may as
        well be set to zero.  If you are using them, you will probably
        want <varname>max_prepared_transactions</varname> to be at least
        as large as <xref linkend="guc-max-connections">, to avoid unwanted
        failures at the prepare step.
       </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 those parameters, if necessary.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-work-mem" xreflabel="work_mem">
      <term><varname>work_mem</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>work_mem</> configuration parameter</primary>
      </indexterm>
      <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 such operations
        concurrently.  So the total memory used could be many
        times the value of <varname>work_mem</varname>; it is necessary to
        keep this fact in mind when choosing the value. Sort operations are
        used for <literal>ORDER BY</>, <literal>DISTINCT</>, and
        merge joins.
        Hash tables are used in hash joins, hash-based aggregation, and
        hash-based processing of <literal>IN</> subqueries.
       </para>
      </listitem>
     </varlistentry>
     
     <varlistentry id="guc-maintenance-work-mem" xreflabel="maintenance_work_mem">
      <term><varname>maintenance_work_mem</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>maintenance_work_mem</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Specifies the maximum amount of memory to be used in maintenance
        operations, such as <command>VACUUM</command>, <command>CREATE
        INDEX</>, and <command>ALTER TABLE ADD FOREIGN KEY</>.
        The value is specified in kilobytes, and defaults to 16384 kilobytes
        (16 MB).  Since only one of these operations can be executed at 
        a time by a database session, and an installation normally doesn't
        have very many of them happening concurrently, it's safe to set this
        value significantly larger than <varname>work_mem</varname>.  Larger
        settings may improve performance for vacuuming and for restoring
        database dumps.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-max-stack-depth" xreflabel="max_stack_depth">
      <term><varname>max_stack_depth</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>max_stack_depth</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Specifies the maximum safe depth of the server's execution stack.
        The ideal setting for this parameter is the actual stack size limit
        enforced by the kernel (as set by <literal>ulimit -s</> or local
        equivalent), less a safety margin of a megabyte or so.  The safety
        margin is needed because the stack depth is not checked in every
        routine in the server, but only in key potentially-recursive routines
        such as expression evaluation.  Setting the parameter higher than
        the actual kernel limit will mean that a runaway recursive function
        can crash an individual backend process.  The default setting is
        2048 KB (two megabytes), which is conservatively small and unlikely
        to risk crashes.  However, it may be too small to allow execution
        of complex functions.
       </para>
      </listitem>
     </varlistentry>

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

     <indexterm>
      <primary>free space map</primary>
     </indexterm>

     <para>
      These parameters control the size of the shared <firstterm>free space
      map</>, which tracks the locations of unused space in the database.
      An undersized free space map may cause the database to consume
      increasing amounts of disk space over time, because free space that
      is not in the map cannot be re-used; instead <productname>PostgreSQL</>
      will request more disk space from the operating system when it needs
      to store new data.
      The last few lines displayed by a database-wide <command>VACUUM VERBOSE</> 
      command can help in determining if the current settings are adequate.
      A <literal>NOTICE</> message is also printed during such an operation
      if the current settings are too low.
     </para>

     <para>
      Increasing these parameters 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 those parameters, if necessary.
     </para>

     <variablelist>
     <varlistentry id="guc-max-fsm-pages" xreflabel="max_fsm_pages">
      <term><varname>max_fsm_pages</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>max_fsm_pages</> configuration parameter</primary>
      </indexterm>
      <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 id="guc-max-fsm-relations" xreflabel="max_fsm_relations">
      <term><varname>max_fsm_relations</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>max_fsm_relations</> configuration parameter</primary>
      </indexterm>
      <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
        seventy 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>
     </sect2>
     <sect2 id="runtime-config-resource-kernel">
     <title>Kernel Resource Usage</title>
     <variablelist>

     <varlistentry id="guc-max-files-per-process" xreflabel="max_files_per_process">
      <term><varname>max_files_per_process</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>max_files_per_process</> configuration parameter</primary>
      </indexterm>
      <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 id="guc-preload-libraries" xreflabel="preload_libraries">
      <term><varname>preload_libraries</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>preload_libraries</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>