<!-- $Header: /usr/prj/pg/cvsroot/doc/doc/src/sgml/wal.sgml,v 1.13 2001/08/28 02:17:26 i-kaori Exp $ -->

<chapter id="wal">
<!-- <title>Write-Ahead Logging (<acronym>WAL</acronym>)</title> -->
 <title>ログ先行書き込みプロトコルに基づくロギング――Write-Ahead Logging（<acronym>WAL</acronym>）</title>
<indexterm><primary>WAL</primary></indexterm><indexterm><primary>PostgreSQL</primary><secondary>WAL</secondary></indexterm>
<indexterm><primary sortas="ろぐせんこうかきこみぷろとこるにもとづくろぎんぐ">ログ先行書き込みプロトコルに基づくロギング</primary></indexterm><indexterm><primary>Write Ahead Logging</primary></indexterm>
 <note>
<!--  <title>Author</title> -->
  <title>著者</title>
  <para>
   Vadim Mikheev、Oliver Elphick
  </para>
 </note>

 <sect1 id="wal-general">
<!--  <title>General Description</Title> -->
  <title>概説</Title>

<!--  <para>
   <firstterm>Write Ahead Logging</firstterm> (<acronym>WAL</acronym>)
   is a standard approach to transaction logging.  Its detailed
   description may be found in most (if not all) books about
   transaction processing. Briefly, <acronym>WAL</acronym>'s central
   concept is that changes to data files (where tables and indices
   reside) must be written only after those changes have been logged -
   that is, when log records have been flushed to permanent
   storage. When we follow this procedure, we do not need to flush
   data pages to disk on every transaction commit, because we know
   that in the event of a crash we will be able to recover the
   database using the log: any changes that have not been applied to
   the data pages will first be redone from the log records (this is
   roll-forward recovery, also known as REDO) and then changes made by
   uncommitted transactions will be removed from the data pages
   (roll-backward recovery - UNDO).
  </para> -->

  <para>
   <firstterm>Write Ahead Logging</firstterm>（<acronym>WAL</acronym>）
   はトランザクションロギングを行うための一般的な手法です。詳しい説明はすべてでなくても、たいていのトランザクション処理について書かれた本に書かれています。<acronym>WAL</acronym>の基本的な考え方は、テーブルやインデックスがあるデータファイルに書く前に変更分が先立ってロギングされていなければいけないという点にあります。すなわち、ログレコードが永続的な記憶装置に吐き出されてからということになります。このような手順に従って処理を行えば、たとえクラッシュがおきてもログを使ってデータベースをリカバリできるため、トランザクションのコミットのたびにデータページをディスクに吐き出す必要がなくなります。リカバリの時点では、データページに対してまだ行われていない変更分はログレコードを使って再実行されます（これがロールフォワードリカバリです。すなわちREDOとして知られています）。また、コミットされていないトランザクションはデータページから削除されます（これはロールバックワードリカバリ、すなわちUNDOとして知られています）。
   </para>

  <sect2 id="wal-benefits-now">
<!--   <title>Immediate Benefits of <acronym>WAL</acronym></title> -->
   <title><acronym>WAL</acronym>による当面のメリット</title>
<indexterm><primary>WAL</primary><secondary sortas="めりっと">メリット</secondary></indexterm>

<!--   <para>
    The first obvious benefit of using <acronym>WAL</acronym> is a
    significantly reduced number of disk writes, since only the log
    file needs to be flushed to disk at the time of transaction
    commit; in multi-user environments, commits of many transactions
    may be accomplished with a single <function>fsync()</function> of
    the log file. Furthermore, the log file is written sequentially,
    and so the cost of syncing the log is much less than the cost of
    flushing the data pages.
   </para> -->

   <para>
    <acronym>WAL</acronym>を採用する1つ目の明白な利点はディスクへの書き込み回数が大幅に減ることです。というのは、トランザクションコミットのときにログファイルだけをディスクに吐き出せばよいからです。マルチユーザー環境では多くのトランザクションのコミットをログファイルへの1回の<function>fsync()</function>で済ますことができます。それだけではなく、ログファイルへの書き込みはシーケンシャルに書き込まれるため、データページを吐き出すコストに比べログファイルへの書き込みはずっと低コストになります。

   </para>

<!--    The next benefit is consistency of the data pages. The truth is
    that, before <acronym>WAL</acronym>,
    <productname>PostgreSQL</productname> was never able to guarantee
    consistency in the case of a crash.  Before
    <acronym>WAL</acronym>, any crash during writing could result in: -->

    <para>

    2つ目のメリットは、データページの一貫性です。実際、<acronym>WAL</acronym>が導入される前は、<productname>PostgreSQL</productname>はクラッシュしたときに一貫性を保てるという保証はありませんでした。<acronym>WAL</acronym>導入以前では、書き込み中にクラッシュした場合に次のようなことが起こる可能性がありました。

    <orderedlist>
     <listitem>
<!--      <simpara>index tuples pointing to non-existent table rows</simpara> -->
      <simpara>存在しないテーブルの行をインデックスタプルが指す</simpara>

     </listitem>

     <listitem>
<!--      <simpara>index tuples lost in split operations</simpara> -->
      <simpara>（B-treeの）分割中にインデックスタプルが失われる</simpara>

     </listitem>

     <listitem>
<!--      <simpara>totally corrupted table or index page content, because
      of partially written data pages</simpara> -->
      <simpara>部分的にしかデータが書かれていないために、完全にテーブルやインデックスのページの内容が壊れてしまう</simpara>

     </listitem>
    </orderedlist>

<!--    Problems with indices (problems 1 and 2) could possibly have been
    fixed by additional <function>fsync()</function> calls, but it is
    not obvious how to handle the last case without
    <acronym>WAL</acronym>; <acronym>WAL</acronym> saves the entire
    data page content in the log if that is required to ensure page
    consistency for after-crash recovery. -->

    このインデックスに関わる問題（上記の1と2）は、<function>fsync()</function>の呼び出しを追加すれば解決できる可能性があります。しかし<acronym>WAL</acronym>がない場合、最後の問題を解決するかというのはわかりません。<acronym>WAL</acronym>はページ全体の内容をログファイルに保存し、必要ならばクラッシュリカバリのときにページ内容の一貫性を保つために使います。

   </para>
  </sect2>
  
  <sect2 id="wal-benefits-later">
<!--   <title>Future Benefits</title> -->
   <title>将来のメリット</title>

   <para>
<!--    In this first release of <acronym>WAL</acronym>, UNDO operation is
    not implemented, because of lack of time. This means that changes
    made by aborted transactions will still occupy disk space and that
    we still need a permanent <filename>pg_log</filename> file to hold
    the status of transactions, since we are not able to re-use
    transaction identifiers.  Once UNDO is implemented,
    <filename>pg_log</filename> will no longer be required to be
    permanent; it will be possible to remove
    <filename>pg_log</filename> at shutdown, split it into segments
    and remove old segments. -->

    今回のこの<acronym>WAL</acronym>の最初の実装では、時間が足りなかったのでUNDO操作は実装されていません。このためアボートしたトランザクションは依然としてディスクスペースを使っており、トランザクションの状態を記録するために永続的な<filename>pg_log</filename>ファイルを必要としています。何故なら、トランザクション識別子を再利用することができないからです。ひとたびUNDOが実装されれば、<filename>pg_log</filename>を永続的に保持する必要はありません。<filename>pg_log</filename>をセグメントに分割し、古いセグメントを削除することによってシャットダウンのときに<filename>pg_log</filename>を削除することができます。

   </para>

   <para>
<!--    With UNDO, it will also be possible to implement
    <firstterm>savepoints</firstterm> to allow partial rollback of
    invalid transaction operations (parser errors caused by mistyping
    commands, insertion of duplicate primary/unique keys and so on)
    with the ability to continue or commit valid operations made by
    the transaction before the error.  At present, any error will
    invalidate the whole transaction and require a transaction abort. -->

    またUNDOによって、<firstterm>savepoints</firstterm>を実装することができます。そうすれば、不正なトランザクション処理（入力ミスによるパースエラー、重複したプライマリ/一意キーへの挿入、など）を部分的にロールバックすることができます。savepointsはトランザクションのエラーになる前に実行された有効な操作を継続またはコミットすることができます。今のところ、どんなエラーもトランザクション全体を無効にするので、トランザクションのアボートが必要になります。

   </para>


<!--
    <para>
    <acronym>WAL</acronym> offers the opportunity for a new method for
    database on-line backup and restore (<acronym>BAR</acronym>).  To
    use this method, one would have to make periodic saves of data
    files to another disk, a tape or another host and also archive the
    <acronym>WAL</acronym> log files.  The database file copy and the
    archived log files could be used to restore just as if one were
    restoring after a crash. Each time a new database file copy was
    made the old log files could be removed.  Implementing this
    facility will require the logging of data file and index creation
    and deletion; it will also require development of a method for
    copying the data files (operating system copy commands are not
    suitable). -->
   <para>
    <acronym>WAL</acronym>によって、データベースのオンラインバックアップとリストア（<acronym>BAR</acronym>）を行うための新しい方法を実装できる可能性があります。この方法では、定期的にデータファイルを他のディスク、テープ、あるいは他のホストに保存し、また<acronym>WAL</acronym>のログファイルをアーカイブする必要があります。データファイルのコピーとアーカイブされたログを使って、クラッシュの後にリカバリを行ったのと同じ状態にリストアすることができます。データベースファイルコピーを作るたびに古いログファイルを削除してもかまいません。この機能を実装するためには、データファイルとインデックスの生成と削除をロギングすることが必要です。また、データファイルをコピーする手法を開発する必要があります（OSの提供するコピーコマンドは使えません）。
   </para>
  </sect2>
 </sect1>

 <sect1 id="wal-implementation">
<!--  <title>Implementation</title> -->
 <title>実装</title>
<indexterm><primary>WAL</primary><secondary sortas="じっそう">実装</secondary></indexterm>
  <para>
<!--   <acronym>WAL</acronym> is automatically enabled from release 7.1
   onwards. No action is required from the administrator with the
   exception of ensuring that the additional disk-space requirements
   of the <acronym>WAL</acronym> logs are met, and that any necessary
   tuning is done (see <xref linkend="wal-configuration">). -->

<acronym>WAL</acronym>は7.1以降では自動的に有効になります。<acronym>WAL</acronym>ログが必要とする追加ディスク容量を確保すること、そして必要ならばチューニングすることを除いては（<xref linkend="wal-configuration">を参照）、システム管理者は何もする必要はありません。
  </para>

  <para>
<!--   <acronym>WAL</acronym> logs are stored in the directory
   <Filename><replaceable>$PGDATA</replaceable>/pg_xlog</Filename>, as
   a set of segment files, each 16 MB in size.  Each segment is
   divided into 8 kB pages. The log record headers are described in
   <filename>access/xlog.h</filename>; record content is dependent on
   the type of event that is being logged.  Segment files are given
   sequential numbers as names, starting at
   <filename>0000000000000000</filename>.  The numbers do not wrap, at
   present, but it should take a very long time to exhaust the
   available stock of numbers. -->

<acronym>WAL</acronym>は<Filename><replaceable>$PGDATA</replaceable>/pg_xlog</Filename>ディレクトリに、16Mバイトのサイズをもつセグメントファイルの集合として格納されています。セグメントは8Kバイトのページに分割されます。ログレコード用のへッダーは<filename>access/xlog.h</filename>に記述されています。レコード内容は、ログの対象となる事象のタイプによって異なります。セグメントファイルは名前として<filename>0000000000000000</filename>からはじまる順序数が与えられています。いまのところ、数字は巡回しませんが、利用可能な数字を使い尽くすには非常に長い時間がかかるはずです。
  </para>

  <para>
<!--   The <acronym>WAL</acronym> buffers and control structure are in
   shared memory, and are handled by the backends; they are protected
   by spinlocks.  The demand on shared memory is dependent on the
   number of buffers; the default size of the <acronym>WAL</acronym>
   buffers is 64 kB. -->

<acronym>WAL</acronym>バッファは共有メモリ上の制御構造で、バックエンドが使用します。保護はスピンロックで行います。必要な共有メモリの量はバッファの数によります。<acronym>WAL</acronym>バッファはデフォルトでは64Kバイトです。
  </para>

  <para>
<!--   It is of advantage if the log is located on another disk than the
   main database files.  This may be achieved by moving the directory,
   <filename>pg_xlog</filename>, to another location (while the
   postmaster is shut down, of course) and creating a symbolic link
   from the original location in <replaceable>$PGDATA</replaceable> to
   the new location. -->

主要なデータベースファイルが置いてあるディスクとは別のディスクにログを置くと利点があります。これは<filename>pg_xlog</filename>ディレクトリを別の場所に（もちろんpostmasterを終了しておいてから）移動し、<replaceable>$PGDATA</replaceable>の元々の場所からシンボリックリンクを張ることによって可能となります。
  </para>

  <para>
<!--   The aim of <acronym>WAL</acronym>, to ensure that the log is
   written before database records are altered, may be subverted by
   disk drives that falsely report a successful write to the kernel,
   when, in fact, they have only cached the data and not yet stored it
   on the disk.  A power failure in such a situation may still lead to
   irrecoverable data corruption; administrators should try to ensure
   that disks holding <productname>PostgreSQL</productname>'s data and
   log files do not make such false reports. -->

<acronym>WAL</acronym>の目的は、データベースレコードが置き換えられたり、あるいは、実際にはディスクドライブのキャッシュにデータがあり、まだディスクに書き込まれていないのに、書き込みが成功したと嘘の報告をカーネルにするようなディスクドライブによってデータが破壊されたりする前に、ログが書き込まれることを保証することにあります。そのような情況では、電源が落ちた際に、復旧不可能なデータの破壊が起ることがあります。システム管理者は、<productname>PostgreSQL</productname>のデータとログを保持しているディスク装置がそのような嘘の報告をしないように保証するべきです。
  </para>

  <sect2 id="wal-recovery">
<!--   <title>Database Recovery with <acronym>WAL</acronym></title> -->
   <title><acronym>WAL</acronym>によるデータ回復</title>
<indexterm><primary>WAL</primary><secondary sortas="でーたかいふく">データ回復</secondary></indexterm>
   <para>
<!--    After a checkpoint has been made and the log flushed, the
    checkpoint's position is saved in the file
    <filename>pg_control</filename>. Therefore, when recovery is to be
    done, the backend first reads <filename>pg_control</filename> and
    then the checkpoint record; next it reads the redo record, whose
    position is saved in the checkpoint, and begins the REDO operation.
    Because the entire content of the pages is saved in the log on the
    first page modification after a checkpoint, the pages will be first
    restored to a consistent state. -->

チェックポイントが実行され、ログがフラッシュされた後、チェックポイントの位置は<filename>pg_control</filename>に保存されます。したがって、データ回復を行う場合はバックエンドはまず<filename>pg_control</filename>を読み、次にチェックポイントレコードを読みます。そして、チェックポイントに位置が記録されているredoレコードを読み、REDO操作を開始します。チェックポイント後最初のページ変更によってページ内容全体がログに保存されているので、そのページは最初に一貫した状態に復旧されます。<indexterm><primary>pg_control</primary></indexterm><indexterm><primary>WAL</primary><secondary>pg_control</secondary></indexterm>
   </para>

   <para>
<!--    Using <filename>pg_control</filename> to get the checkpoint
    position speeds up the recovery process, but to handle possible
    corruption of <filename>pg_control</filename>, we should actually
    implement the reading of existing log segments in reverse order &bsol;-&bsol;-
    newest to oldest &bsol;-&bsol;- in order to find the last checkpoint.  This has
    not yet been done in release 7.1. -->

<filename>pg_control</filename>のチェックポイント位置を使うことによって回復処理のスピードは早くなりますが、<filename>pg_control</filename>が壊れた場合に備え、ログセグメントを逆順に読み（すなわち新しいものから古いものへと）、最終チェックポイントを見付ける方法を実際には実装した方がよいと思われます。リリース7.1ではまだこれはできていません。
   </para>
  </sect2>
 </sect1>

 <sect1 id="wal-configuration">
<!--  <title><acronym>WAL</acronym> Configuration</title> -->
  <title><acronym>WAL</acronym>の設定</title>
<indexterm><primary>WAL</primary><secondary sortas="せってい">設定</secondary></indexterm>
  <para>
<!--   There are several <acronym>WAL</acronym>-related parameters that
   affect database performance. This section explains their use.
   Consult <xref linkend="runtime-config"> for details about setting
   configuration parameters. -->

データベースの性能に影響するような<acronym>WAL</acronym>に関連したパラメータがあります。この節では、その使い方を説明します。設定方法の詳細については<xref linkend="runtime-config">を参照してください。
  </para>

  <para>
<!--   There are two commonly used <acronym>WAL</acronym> functions:
   <function>LogInsert</function> and <function>LogFlush</function>.
   <function>LogInsert</function> is used to place a new record into
   the <acronym>WAL</acronym> buffers in shared memory. If there is no
   space for the new record, <function>LogInsert</function> will have
   to write (move to kernel cache) a few filled <acronym>WAL</acronym>
   buffers. This is undesirable because <function>LogInsert</function>
   is used on every database low level modification (for example,
   tuple insertion) at a time when an exclusive lock is held on
   affected data pages and the operation is supposed to be as fast as
   possible; what is worse, writing <acronym>WAL</acronym> buffers may
   also cause the creation of a new log segment, which takes even more
   time. Normally, <acronym>WAL</acronym> buffers should be written
   and flushed by a <function>LogFlush</function> request, which is
   made, for the most part, at transaction commit time to ensure that
   transaction records are flushed to permanent storage. On systems
   with high log output, <function>LogFlush</function> requests may
   not occur often enough to prevent <acronym>WAL</acronym> buffers
   being written by <function>LogInsert</function>. On such systems
   one should increase the number of <acronym>WAL</acronym> buffers by
   modifying the <varname>WAL_BUFFERS</varname> parameter. The default
   number of <acronym>WAL</acronym> buffers is 8.  Increasing this
   value will have an impact on shared memory usage. -->

   <acronym>WAL</acronym>には2つの共通関数があります。<function>LogInsert</function>と<function>LogFlush</function>です。<function>LogInsert</function>は共有メモリ上の<acronym>WAL</acronym>バッファに新しいレコードを挿入します。新しいレコードを挿入する余地がないときは、<function>LogInsert</function>は、満杯になった<acronym>WAL</acronym>を書き込み（カーネルキャッシュに移動）しなければいけません。これは望ましいことではありません。なぜなら、データベースへの低レベルの変更（たとえばタプルの挿入）のたびに<function>LogInsert</function>が呼ばれますが、そのような場合には変更を受けたページに対して排他ロックがかっており、それ故このような操作は可能な限り高速に実行されると想定されているからです。さらに悪いことには、<acronym>WAL</acronym>に必要な新しいログセグメントも必要となるかもしれません。この場合、さらに時間がかかります。通常、<acronym>WAL</acronym>の書き込み、吐き出しは<function>LogFlush</function>要求で実施されます。これはたいていの場合、トランザクションコミットの際に永続記憶にトランザクションレコードが吐き出されることを保証するために行われます。ログ出力が大量に行われるシステムでは、<function>LogInsert</function>が<acronym>WAL</acronym>バッファの書き込みを行うことを防ぐほどには<function>LogFlush</function>要求が頻繁に起らないかもしれません。そういうシステムでは、<varname>WAL_BUFFERS</varname>変数を変更して<acronym>WAL</acronym>バッファの数を増やしてください。デフォルトの<acronym>WAL</acronym>の数は8です。この数を増やすと共有メモリの使用量に影響があります。<indexterm><primary>WAL</primary><secondary>LogInsert</secondary></indexterm><indexterm><primary>WAL</primary><secondary>LogFlush</secondary></indexterm><indexterm><primary>WAL_BUFFERS</primary></indexterm><indexterm><primary sortas="かんきょうへんすう">環境変数</primary><secondary>WAL_BUFFERS</secondary></indexterm>

  </para>

  <para>
<!--   <firstterm>Checkpoints</firstterm> are points in the sequence of
   transactions at which it is guaranteed that the data files have
   been updated with all information logged before the checkpoint.  At
   checkpoint time, all dirty data pages are flushed to disk and a
   special checkpoint record is written to the log file. As result, in
   the event of a crash, the recoverer knows from what record in the
   log (known as the redo record) it should start the REDO operation,
   since any changes made to data files before that record are already
   on disk. After a checkpoint has been made, any log segments written
   before the redo record are removed, so checkpoints are used to free
   disk space in the <acronym>WAL</acronym> directory. (When
   <acronym>WAL</acronym>-based <acronym>BAR</acronym> is implemented,
   the log segments can be archived instead of just being removed.)
   The checkpoint maker is also able to create a few log segments for
   future use, so as to avoid the need for
   <function>LogInsert</function> or <function>LogFlush</function> to
   spend time in creating them. -->

   <firstterm>チェックポイント</firstterm>は、一連のトランザクションにおいて、それ以前のすべてのデータがログされ、データファイルも更新されていることが保証されている時点を指します。チェックポイントでは、すべての変更されたページがディスクに吐き出され、特別なチェックポイントレコードがログファイルに書き込まれます。その結果、クラッシュが発生した際に、ログの中でどのレコード（これはredoレコードと呼ばれています）から復旧処理がREDOログ操作を開始すべきかを知ることができます。なぜなら、redoレコード以前にデータファイルに対して行われた変更はすでにディスク上に記録済みだからです。チェックポイントが実施された後、redoレコード以前のログセグメントはすべて削除されます。そこで、チェックポイントを使って<acronym>WAL</acronym>ディレクトリ以下のディスクスペースを解放することができます（<acronym>WAL</acronym>を使った<acronym>BAR</acronym>が実装されれば、ログセグメントを削除する代わりに保存することができます）。チェックポイントでは、<function>LogInsert</function>や<function>LogFlush</function>が新しくログセグメントを作るために時間を費やすことのないように、前もってログセグメントを作っておくこともできます。<indexterm><primary sortas="ちぇっくぽいんと">チェックポイント</primary></indexterm><indexterm><primary>WAL</primary><secondary sortas="ちぇっくぽいんと">チェックポイント</secondary></indexterm><indexterm><primary>WAL</primary><secondary sortas="redoれこーど">redoレコード</secondary></indexterm>
  </para>

  <para>
<!--   The <acronym>WAL</acronym> log is held on the disk as a set of 16
   MB files called <firstterm>segments</firstterm>.  By default a new
   segment is created only if more than 75% of the current segment is
   used. One can instruct the server to pre-create up to 64 log segments
   at checkpoint time by modifying the <varname>WAL_FILES</varname>
   configuration parameter. -->

   <acronym>WAL</acronym>ログは<firstterm>segments</firstterm>と呼ばれる16Mバイトのファイルのセットに保持されています。デフォルトではセグメントの75%以上が使われたときにだけ新しいセグメントが作成されます。<varname>WAL_FILES</varname>設定パラメータを調整することにより、64個までのログセグメントを前もって作成することができます。
  </para>

  <para>
<!--   For faster after-crash recovery, it would be better to create
   checkpoints more often.  However, one should balance this against
   the cost of flushing dirty data pages; in addition, to ensure data
   page consistency, the first modification of a data page after each
   checkpoint results in logging the entire page content, thus
   increasing output to log and the log's size. -->

   クラッシュ後の回復をより早くするためには、頻繁にチェックポイントを行うことが大切です。ただし、変更されたページを吐き出すコストとの兼ね合いになります。また、チェックポイント後の最初のデータページの変更によりそのページ内容全体がログされます。したがって、ログする量が増えるので、ログファイルのサイズも大きくなってしまいます。
  </para>

  <para>
<!--   The postmaster spawns a special backend process every so often
   to create the next checkpoint.  A checkpoint is created every
   <varname>CHECKPOINT_SEGMENTS</varname> log segments, or every
   <varname>CHECKPOINT_TIMEOUT</varname> seconds, whichever comes first.
   The default settings are 3 segments and 300 seconds respectively.
   It is also possible to force a checkpoint by using the SQL command
   <command>CHECKPOINT</command>. -->

   postmasterは次のチェックポイントを作成するために特別なバックエンドを頻繁に起動します。<varname>CHECKPOINT_SEGMENTS</varname>ログセグメント数に達するか、または<varname>CHECKPOINT_TIMEOUT</varname>秒が経過するか、どちらかの条件が満たされるとチェックポイントが作成されます。デフォルトの設定では、それぞれ3セグメントと300秒となっています。また、SQLコマンドの<command>CHECKPOINT</command>で強制的にチェックポイントを作成することもできます。
  </para>

  <para>
<!--   The <varname>COMMIT_DELAY</varname> parameter defines for how many
   microseconds the backend will sleep after writing a commit
   record to the log with <function>LogInsert</function> but before
   performing a <function>LogFlush</function>. This delay allows other
   backends to add their commit records to the log so as to have all
   of them flushed with a single log sync. No sleep will occur if fsync
   is not enabled or if fewer than <varname>COMMIT_SIBLINGS</varname>
   other backends are not currently in active transactions; this avoids
   sleeping when it's unlikely that any other backend will commit soon.
   Note that on most platforms, the resolution of a sleep request is
   ten milliseconds, so that any nonzero <varname>COMMIT_DELAY</varname>
   setting between 1 and 10000 microseconds will have the same effect. -->

   <varname>COMMIT_DELAY</varname>パラメータにより、<function>LogInsert</function>がコミットレコードを書き込んでから<function>LogFlush</function>が行われるまでの間にバックエンドが何マイクロ秒sleepするかが決まります。この遅延があることにより、ほかのバックエンドがコミットレコードをログに書き込んだあと、それらすべてのログレコードを1回のfsyncで吐出すことができます。もし<varname>COMMIT_SIBLINGS</varname>よりも少ない数のバックエンドしか現在アクティブなトランザクションに存在しない場合は、sleepしません。このことにより、すぐにコミットしそうなバックエンドがいないときでもsleepするのを防ぐことができます。たいていのプラットフォームでは、sleepの最小単位はミリ秒です。ですから、0以外の<varname>COMMIT_DELAY</varname>の設定は、1マイクロ秒から10,000マイクロ秒まで効果は同じことになるでしょう。
  </para>

  <para>
<!--   The <varname>WAL_SYNC_METHOD</varname> parameter determines how
   Postgres will ask the kernel to force WAL updates out to disk.
   All the options should be the same as far as reliability goes,
   but it's quite platform-specific which one will be the fastest.
   Note that this parameter is irrelevant if <varname>FSYNC</varname>
   has been turned off. -->

   <varname>WAL_SYNC_METHOD</varname>パラメータはPostgresがカーネルに対してWAL更新のディスクへの書き込みを依頼する方法を決定します。どういう設定でも信頼性は同じはずですが、プラットフォームによってどれが一番早いかは全然違います。ちなみに、このパラメータは<varname>FSYNC</varname>が無効になっている場合は無関係です。

  </para>

  <para>
<!--   Setting the <varname>WAL_DEBUG</varname> parameter to any non-zero
   value will result in each <function>LogInsert</function> and
   <function>LogFlush</function> <acronym>WAL</acronym> call being
   logged to standard error.  At present, it makes no difference what
   the non-zero value is.  This option may be replaced by a more
   general mechanism in the future. -->

   <varname>WAL_DEBUG</varname>を0以外のどんな値にしても、<function>LogInsert</function>と<function>LogFlush</function>の<acronym>WAL</acronym>における呼び出しが標準エラー出力に出力されるようになります。いまのところ、値による違いはありません。将来はもっと汎用的な方法に置き換えられるかもしれません。
  </para>
 </sect1>
</chapter>

<!-- 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:
-->
