config.sgml

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

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

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

    <sect2 id="runtime-config-wal-settings">
     <title>Settings</title>
     <variablelist>
     
     <varlistentry id="guc-fsync" xreflabel="fsync">
      <indexterm>
       <primary><varname>fsync</> configuration parameter</primary>
      </indexterm>
      <term><varname>fsync</varname> (<type>boolean</type>)</term>
      <listitem>
       <para>
        If this option is on, the <productname>PostgreSQL</> server
        will try to make sure that updates are physically written to
        disk, by issuing <function>fsync()</> system calls or various
        equivalent methods (see <xref linkend="guc-wal-sync-method">).
        This ensures that the database cluster can recover to a
        consistent state after an operating system or hardware crash.
       </para>

       <para>
        However, using <varname>fsync</varname> results in a
        performance penalty: when a transaction is committed,
        <productname>PostgreSQL</productname> must wait for the
        operating system to flush the write-ahead log to disk.  When
        <varname>fsync</varname> is disabled, the operating system is
        allowed to do its best in buffering, ordering, and delaying
        writes. This can result in significantly improved performance.
        However, if the system crashes, the results of the last few
        committed transactions may be lost in part or whole. In the
        worst case, unrecoverable data corruption may occur.
        (Crashes of the database software itself are <emphasis>not</>
        a risk factor here.  Only an operating-system-level crash
        creates a risk of corruption.)
       </para>

       <para>
        Due to the risks involved, there is no universally correct
        setting for <varname>fsync</varname>. Some administrators
        always disable <varname>fsync</varname>, while others only
        turn it off during initial bulk data loads, where there is a clear
        restart point if something goes wrong.  Others
        always leave <varname>fsync</varname> enabled. The default is
        to enable <varname>fsync</varname>, for maximum reliability.
        If you trust your operating system, your hardware, and your
        utility company (or your battery backup), you can consider
        disabling <varname>fsync</varname>.
       </para>

       <para>
        This option can be set at server start or in the
        <filename>postgresql.conf</filename> file.  If you turn
        this option off, also consider turning off 
        <xref linkend="guc-full-page-writes">.
       </para>
      </listitem>
     </varlistentry>
     
     <varlistentry id="guc-wal-sync-method" xreflabel="wal_sync_method">
      <term><varname>wal_sync_method</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>wal_sync_method</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Method used for forcing WAL updates out to disk.
        If <varname>fsync</varname> is off then this setting is irrelevant,
        since updates will not be forced out at all.
        Possible values are:
       </para>
       <itemizedlist>
        <listitem>
        <para>
         <literal>open_datasync</> (write WAL files with <function>open()</> option <symbol>O_DSYNC</>)
        </para>
        </listitem>
        <listitem>
        <para>
         <literal>fdatasync</> (call <function>fdatasync()</> at each commit)
        </para>
        </listitem>
        <listitem>
        <para>
         <literal>fsync_writethrough</> (call <function>fsync()</> at each commit, forcing write-through of any disk write cache)
        </para>
        </listitem>
        <listitem>
        <para>
         <literal>fsync</> (call <function>fsync()</> at each commit)
        </para>
        </listitem>
        <listitem>
        <para>
         <literal>open_sync</> (write WAL files with <function>open()</> option <symbol>O_SYNC</>)
        </para>
        </listitem>
       </itemizedlist>
       <para>
        Not all of these choices are available on all platforms.
        The default is the first method in the above list that is supported.
        This option can be set at server start or in the
        <filename>postgresql.conf</filename> file.
       </para>
      </listitem>
     </varlistentry>
     
     <varlistentry id="guc-full-page-writes" xreflabel="full_page_writes">
      <indexterm>
       <primary><varname>full_page_writes</> configuration parameter</primary>
      </indexterm>
      <term><varname>full_page_writes</varname> (<type>boolean</type>)</term>
      <listitem>
       <para>
        When this option is on, the <productname>PostgreSQL</> server
        writes the entire content of each disk page to WAL during the
        first modification of that page after a checkpoint.
       </para>

       <para>
        This parameter is currently ignored (treated as always <literal>on</>)
        because turning it off can cause failure to recover from crashes
        even when no hardware or OS-level error occurred.  This will be
        fixed in some future release, or else the parameter will be removed
        entirely.
       </para>
      </listitem>
     </varlistentry>
     
     <varlistentry id="guc-wal-buffers" xreflabel="wal_buffers">
      <term><varname>wal_buffers</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>wal_buffers</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Number of disk-page buffers allocated in shared memory for WAL data.
        The default is 8.  The setting need only be large enough to hold
        the amount of WAL data generated by one typical transaction, since
        the data is written out to disk at every transaction commit.
        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-commit-delay" xreflabel="commit_delay">
      <term><varname>commit_delay</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>commit_delay</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Time delay between writing a commit record to the WAL buffer
        and flushing the buffer out to disk, in microseconds. A
        nonzero delay can allow multiple transactions to be committed
        with only one <function>fsync()</function> system call, if
        system load is high enough that additional transactions become
        ready to commit within the given interval. But the delay is
        just wasted if no other transactions become ready to
        commit. Therefore, the delay is only performed if at least
        <varname>commit_siblings</varname> other transactions are
        active at the instant that a server process has written its
        commit record. The default is zero (no delay).
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-commit-siblings" xreflabel="commit_siblings">
      <term><varname>commit_siblings</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>commit_siblings</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Minimum number of concurrent open transactions to require
        before performing the <varname>commit_delay</> delay. A larger
        value makes it more probable that at least one other
        transaction will become ready to commit during the delay
        interval. The default is five.
       </para>
      </listitem>
     </varlistentry>

     </variablelist>
     </sect2>
     <sect2 id="runtime-config-wal-checkpoints">
     <title>Checkpoints</title>

    <variablelist>
     <varlistentry id="guc-checkpoint-segments" xreflabel="checkpoint_segments">
      <term><varname>checkpoint_segments</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>checkpoint_segments</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Maximum distance between automatic WAL checkpoints, in log
        file segments (each segment is normally 16 megabytes). The
        default is three.  This option can only be set at server start
        or in the <filename>postgresql.conf</filename> file.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-checkpoint-timeout" xreflabel="checkpoint_timeout">
      <term><varname>checkpoint_timeout</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>checkpoint_timeout</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Maximum time between automatic WAL checkpoints, in
        seconds. The default is 300 seconds.  This option can only be
        set at server start or in the <filename>postgresql.conf</>
        file.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-checkpoint-warning" xreflabel="checkpoint_warning">
      <term><varname>checkpoint_warning</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>checkpoint_warning</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Write a message to the server log if checkpoints caused by
        the filling of checkpoint segment files happen closer together
        than this many seconds (which suggests that
        <varname>checkpoint_segments</> ought to be raised).  The default is
        30 seconds.  Zero disables the warning.
       </para>
      </listitem>
     </varlistentry>

     </variablelist>
     </sect2>
     <sect2 id="runtime-config-wal-archiving">
     <title>Archiving</title>

    <variablelist>
     <varlistentry id="guc-archive-command" xreflabel="archive_command">
      <term><varname>archive_command</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>archive_command</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        The shell command to execute to archive a completed segment of
        the WAL file series. If this is an empty string (the default),
        WAL archiving is disabled. Any <literal>%p</> in the string is
        replaced by the absolute path of the file to archive, and any
        <literal>%f</> is replaced by the file name only. Use
        <literal>%%</> to embed an actual <literal>%</> character in the
        command. For more information see <xref
        linkend="backup-archiving-wal">. This option can only be set at
        server start or in the <filename>postgresql.conf</filename>
        file.
       </para>
       <para>
        It is important for the command to return a zero exit status if
        and only if it succeeds.  Examples:
<programlisting>
archive_command = 'cp "%p" /mnt/server/archivedir/"%f"'
archive_command = 'copy "%p" /mnt/server/archivedir/"%f"'  # Windows
</programlisting>
       </para>
      </listitem>
     </varlistentry>
     
     </variablelist>
    </sect2>
   </sect1>

   <sect1 id="runtime-config-query">
    <title>Query Planning</title>

    <sect2 id="runtime-config-query-enable">
     <title>Planner Method Configuration</title>

      <para>
       These configuration parameters provide a crude method of
       influencing the query plans chosen by the query optimizer. If
       the default plan chosen by the optimizer for a particular query
       is not optimal, a temporary solution may be found by using one
       of these configuration parameters to force the optimizer to
       choose a different plan.  Turning one of these settings off
       permanently is seldom a good idea, however.