<!--
$Header: /usr/prj/pg/cvsroot/doc/doc/src/sgml/runtime.sgml,v 1.17 2001/09/12 07:58:13 k-kondo Exp $
-->

<Chapter Id="runtime">
<!--  <Title>Server Runtime Environment</Title>-->
 <Title>サーバー実行時環境</Title>
<indexterm><primary sortas="さーばーじっこうじかんきょう">サーバー実行時環境</primary></indexterm>
<indexterm><primary>PostgreSQL</primary><secondary sortas="さーばーじっこうじかんきょう">サーバー実行時環境</secondary></indexterm>
 <para>
  <!-- This chapter discusses how to set up and run the database server
  and the interactions with the operating system. -->

  この章では、データベースサーバーの設定と実行方法、そしてオペレーティングシステム（OS）との相互作用について説明します。

 </para>

 <sect1 id="postgres-user">
  <!-- <title>The Postgres user account</title> -->
  <title>Postgresのユーザーアカウント</title>
<indexterm><primary>PostgreSQL</primary><secondary sortas="ゆーざーあかうんと">ユーザーアカウント</secondary></indexterm>
<indexterm><primary sortas="ゆーざーあかうんと">ユーザーアカウント</primary></indexterm>
  <para>
   <!-- As with any other server daemon that is connected to the world at
   large, it is advisable to run Postgres under a separate user
   account. This user account should only own the data itself that is
   being managed by the server, and should not be shared with other
   daemons. (Thus, using the user <quote>nobody</quote> is a bad
   idea.) It is not advisable to install the executables as owned by
   this user account because that runs the risk of user-defined
   functions gone astray or any other exploits compromising the
   executable programs. -->

   一般世間と繋がっている他のサーバーデーモンと同じように、Postgresを別のユーザーで実行することをお勧めします。このユーザーアカウントは、そのサーバーに管理されているデータのみを所有するべきで、他のデーモンと共有されるべきではありません（したがって、ユーザー<quote>nobody</quote>を使うことは好ましくありません）。また、このユーザーアカウントが所有している実行プログラムをインストールすることも好ましくありません。なぜならば、ユーザー定義関数に問題が発生するなどの、実行プログラムを損なうようなリスクを冒すからです。


  </para>

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

   システムにユーザーアカウントを追加するためには、<command>useradd</command>コマンドか<command>adduser</command>コマンドを使用してください。通常はユーザー名<quote>postgres</quote>が使われますが、必ずしもそうである必要はありません。

  </para>
 </sect1>

 <sect1 id="creating-cluster">
  <!-- <title>Creating a database cluster</title> -->
  <title>データベースクラスタの作成</title>
<indexterm><primary>PostgreSQL</primary><secondary sortas="でーたべーすくらすたのさくせい">データベースクラスタの作成</secondary></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> speaks of a catalog
   cluster instead.) A database cluster is a collection of databases
   that will be accessible through a single instance of a running
   database server. After initialization, a database cluster will
   contain one database named <literal>template1</literal>. As the
   name suggests, this will be used as a template for any subsequently
   created database; it should not be used for actual work. -->

   まず第一に、ディスクのデータベース格納領域を初期化する必要があります。この格納領域が<firstterm>データベースクラスタ</firstterm>と呼ばれるものです（<acronym>SQL</acronym>では代わりにカタログクラスタと呼びます）。<indexterm><primary sortas="でーたべーすくらすた">データベースクラスタ</primary></indexterm><indexterm><primary>PostgreSQL</primary><secondary sortas="でーたべーすくらすた">データベースクラスタ</secondary></indexterm>データベースクラスタはデータベースの集合で、稼働しているデータベースサーバーの1つのインスタンスを通してアクセスすることができます。初期化が終わると、データベースクラスタには<literal>template1</literal>と呼ばれるデータベースが1つ作成されています。その名前から推測できるように、これはその後に作成されるデータベースのテンプレートとして使われます。したがって、実際の作業に使用すべきではありません。<indexterm><primary>template1</primary></indexterm><indexterm><primary>PostgreSQL</primary><secondary>template1</secondary></indexterm>

  </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>,
   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>
&gt; <userinput>initdb -D /usr/local/pgsql/data</userinput>
</screen>
   Note that you must execute this command while being logged in to
   the Postgres user account, which is described in the previous
   section. -->

   ファイルシステムの観点から見ると、データベースクラスタというのは、すべてのデータが格納される1つのディレクトリということになります。これは<firstterm>データディレクトリ</firstterm>もしくは<firstterm>データ領域</firstterm>と呼ばれます。<indexterm><primary sortas="でーたでぃれくとり">データディレクトリ</primary></indexterm><indexterm><primary sortas="でーたりょういき">データ領域</primary></indexterm>どこにデータを格納するかは完全にユーザーの自由で、特にデフォルトの領域はありません。一般的によく使われるのは<filename>/usr/local/pgsql/data</filename>か<filename>/var/lib/pgsql/data</filename>です。データベースクラスタを初期化するためには、<productname>PostgreSQL</productname>と一緒にインストールされるコマンド<command>initdb</command>を使います。データベースシステムの中で必要なファイルシステムの場所はオプション<option>-D</option>で示します。たとえば次のようにします。</para>

<screen>
&gt; <userinput>initdb -D /usr/local/pgsql/data</userinput>
</screen>

<para>前節で説明したように、このコマンドはPostgresユーザーアカウントでログインしている間に実行する必要があります。
  </para>

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

    オプション<option>-D</option>を使う代わりに環境変数<envar>PGDATA</envar>を設定することもできます。

   </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 won't
   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 transfer ownership of it to the
   Postgres user account. Here is how this might work: -->

   もし指定したディレクトリが存在しない場合は、<command>initdb</command>がその新しいディレクトリを作成しようとします。しかし（ここのアドバイスにしたがって権限を持たないアカウントで作成した場合など）作成権限がない場合があります。その場合は（rootとして）手動でディレクトリを作成し、その所有権をPostgresユーザーアカウントに変更します。下記がその例となります。</para>

<screen>
root# <userinput>mkdir /usr/local/pgsql/data</userinput>
root# <userinput>chown postgres /usr/local/pgsql/data</userinput>
root# <userinput>su postgres</userinput>
postgres&gt; <userinput>initdb -D /usr/local/pgsql/data</userinput>
</screen>

  <para>
   <!-- 
   <command>initdb</command> will refuse to run if the data directory
   looks like it belongs to an already initialized installation. -->

   もしデータディレクトリがすでに初期化されたインストールで使用されているような場合は、<command>initdb</command>は実行を拒否します。

  </para>

  <para>
   <!-- Because the data directory contains all the data stored in the
   database it is essential that it be well secured from unauthorized
   access. <command>initdb</command> therefore revokes access
   permissions from everyone but the Postgres user account. -->

   データディレクトリにはデータベースの中のすべてのデータが保持されるため、権限を持たない人のアクセスを制限することが大切です。ですから、<command>initdb</command>はPostgresユーザーアカウント以外にはアクセス権を与えません。

  </para>

  <para>
   <!-- 
   One surprise you might encounter while running <command>initdb</command> is
   a notice similar to this one: -->

   <command>initdb</command>を実行し、下記のような注意メッセージが表示されて驚く場合があるかもしれません。</para>

<screen>
NOTICE:  Initializing database with en_US collation order.
        This locale setting will prevent use of index optimization for
        LIKE and regexp searches.  If you are concerned about speed of
        such queries, you may wish to set LC_COLLATE to "C" and
        re-initdb.  For more information see the Administrator's Guide.
</screen>
   <!-- 
   This notice is intended to warn you that the currently selected locale
   will cause indexes to be sorted in an order that prevents them from
   being used for LIKE and regular-expression searches.  If you need
   good performance of such searches, you should set your current locale
   to "C" and re-run <command>initdb</command>.  On most systems, setting the
   current locale is done by changing the value of the environment variable
   <literal>LC_ALL</literal> or <literal>LANG</literal>.  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, re-initdb,
   reload data.  So it's important to make this choice correctly now. -->

<para>この注意メッセージは、現在選択されているロケールでは、インデックスをソートする際にLIKEや正規表現検索を使用しないということを警告しています。LIKEや正規表現のような検索で高い性能を望む場合は、ロケールを「C」にして<command>initdb</command>を再実行してください。ほとんどのシステムにおいて、ロケールの設定は環境変数<literal>LC_ALL</literal>、もしくは<literal>LANG</literal>の値を変えることで行います。特定のデータベースクラスタで使われるソートの順番は<command>initdb</command>で設定されます。後に設定を変更したい場合は、すべてのデータをダンプし、再びinitdbを行ってデータを再読み込みする必要がありますので、ここで正しい選択をしておくことが大切です。

  </para>
 </sect1>

 <sect1 id="postmaster-start">
  <!-- <title>Starting the database server</title> -->
  <title>データベースサーバーの起動</title>
<indexterm><primary sortas="でーたべーすさーばーのきどう">データベースサーバーの起動</primary></indexterm>
<indexterm><primary>PostgreSQL</primary><secondary sortas="でーたべーすさーばーのきどう">データベースサーバーの起動</secondary></indexterm>
  <para>
   <!-- 
   Before anyone can access the database you must start the database
   server. The database server is called
   <firstterm>postmaster</firstterm>.
   The postmaster must know where to find the data it is supposed
   to work on. This is done with the <option>-D</option> option. Thus,
   the simplest way to start the server is, for example,-->

   データベースにアクセスするためには、まずデータベースサーバーを起動しなくてはいけません。データベースサーバーは<firstterm>postmaster</firstterm>と呼ばれます。<indexterm><primary>postmaster</primary></indexterm><indexterm><primary>PostgreSQL</primary><secondary>postmaster</secondary></indexterm>postmasterは自分が作業するデータがどこにあるのかを知っている必要があり、これはオプション<option>-D</option>で指定できます。したがって、サーバーを起動する一番簡単な方法例は、以下のようなコマンドとなります。</para>

<screen>
&gt; <userinput>postmaster -D /usr/local/pgsql/data</userinput>
</screen>

   <!-- 
   which will leave the server running in the foreground. This must
   again be done while logged in to the Postgres user account. Without
   a <option>-D</option>, the server will try to use the data
   directory in the environment variable <envar>PGDATA</envar>; if
   neither of these works it will fail. -->

<para>上記のコマンドは、サーバーをフォアグラウンドで実行させます。これもまたPostgresユーザーアカウントにログインして実行されなくてはいけません。<option>-D</option>オプションが指定されていない場合、サーバーは環境変数<envar>PGDATA</envar>で指定されたデータディレクトリを使用しようと試みます。両方の方法でもできない場合は失敗します。

  </para>

  <para>
   <!-- To start the <application>postmaster</application> in the
   background, use the usual shell syntax: -->

   バックグランドで<application>postmaster</application>を起動するには通常のシェルの構文を使います。</para>

<screen>
&gt; <userinput>postmaster -D /usr/local/pgsql/data &gt; logfile 2&gt;&amp;1 &amp;</userinput>
</screen>
   <!-- It is an extremely good idea to keep the server output around
   somewhere, as indicated here. It will help both for auditing
   purposes and to diagnose problems. -->

<para>この例のように、サーバーの出力をどこかに残しておくことを強くお勧めします。これは追跡記録的な役割と問題の原因究明の2つの役割があります。

  </para>

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

   postmasterには、このほかにも多くのコマンドラインオプションを指定することができます。詳しい情報はリファレンスの実行時設定の部分を参照してください。特に、postmasterが（Unixドメインソケットではなく）TCP/IP接続を受け入れるためにはオプション<option>-i</option>を指定する必要があります。

  </para>

  <para>
   <!-- This shell syntax can get tedious quickly.  Therefore the shell
   script wrapper <application>pg_ctl</application> is provided that
   encapsulates some of the tasks.  E.g., -->

   このシェル構文はすぐに長くなります。したがってシェルスクリプトラッパーである<application>pg_ctl</application>コマンドが提供されていて、いくつかのタスクをカプセル化することができます。たとえば、以下のように使います。<indexterm><primary>pg_ctl</primary></indexterm><indexterm><primary>PostgreSQL</primary><secondary>pg_ctl</secondary></indexterm></para>

<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 as when invoking postmaster directly.
   <application>pg_ctl</application> also implements a symmetric
   <quote>stop</quote> operation. -->

<para>これは、サーバーをバックグラウンドで起動し、出力を指定されたログファイルに書き出します。<option>-D</option>オプションはpostmasterを直接呼び出す場合と同じ意味を持ちます。また、<application>pg_ctl</application>はpostmasterを起動するだけでなく、<quote>stop</quote>することもできます。

  </para>

  <para>
   <!-- Normally, you will want to start the database server when the
   computer boots up. This is not required; the
   <productname>PostgreSQL</productname> server can be run
   successfully from non-privileged accounts without root
   intervention. -->

   通常、コンピュータが起動されたときにデータベースサーバーも一緒に起動する場合が多いと思われます。必ずしもそうする必要はありませんが、<productname>PostgreSQL</productname>サーバーは権限を持たないアカウントからでもrootの介入なしで起動させることができます。

  </para>

  <para>
   <!-- Different systems have different conventions for starting up
   daemons at boot time, so you are advised to familiarize yourself
   with them. Many systems have a file
   <filename>/etc/rc.local</filename> or
   <filename>/etc/rc.d/rc.local</filename> which is almost certainly
   no bad place to put such a command. Whatever you do, the server
   must be run by the <productname>Postgres</productname> user account
   <emphasis>and not by root</emphasis> or any other user. Therefore
   you probably always want to form your command lines along the lines
   of <literal>su -c '...' postgres</literal>, for example: -->

   ブート時にデーモンを開始する方法はシステムによって異なりますが、精通しておいたほうがよいでしょう。多くのシステムには<filename>/etc/rc.local</filename>ファイルや<filename>/etc/rc.d/rc.local</filename>ファイルがあり、それらのコマンドを置いておくには適切な場所だといえます。何を実行するにしても、Postgresサーバーは<productname>Postgres</productname>ユーザーアカウントで起動させます。<emphasis>rootであってはいけません</emphasis>し、他のユーザーでもいけません。したがって、<command>su -c '...' postgres</command>のような専用のコマンドを作っておいたほうがよいでしょう。たとえば次のようなものが考えられます。</para>

<programlisting>
su -c 'pg_ctl -D /usr/local/pgsql/data -l serverlog' postgres
</programlisting>

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

   さらにいくつかのオペレーティングシステム固有の提案を挙げます（適切なインストールディレクトリと自分が選んだユーザー名に置き換えて読んでください）。</para>

   <itemizedlist>
    <listitem>
     <para>
      <!-- For <productname>FreeBSD</productname>, take a look at the file
      <filename>contrib/start-scripts/freebsd</filename> in the
      <productname>PostgreSQL</productname> source distribution. -->

      <productname>FreeBSD</productname>では、<productname>PostgreSQL</productname>で配布されるソースの中にある<filename>contrib/start-scripts/freebsd</filename>ファイルを参照してください。<indexterm><primary>PostgreSQL</primary><secondary>FreeBSD</secondary></indexterm>

     </para>
    </listitem>

    <listitem>
     <para>
      <!-- On <productname>OpenBSD</productname>, add the following lines
      to the file <filename>/etc/rc.local</filename>: -->

      <productname>OpenBSD</productname>では、以下の数行を<filename>/etc/rc.local</filename>ファイルに追加してください。<indexterm><primary>PostgreSQL</primary><secondary>OpenBSD</secondary></indexterm></para>

<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>
    </listitem>

    <listitem>
     <para>
      <!-- On <productname>Linux</productname> systems either add -->
      <productname>Linux</productname>システムでは、以下の行を<filename>/etc/rc.d/rc.local</filename>ファイルに追加してください。<indexterm><primary>PostgreSQL</primary><secondary>Linux</secondary></indexterm></para>

<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 into the file
      <filename>contrib/start-scripts/linux</filename> in the
      <productname>PostgreSQL</productname> source distribution to
      integrate the start and shutdown into the run level system. -->

<para>または、<productname>PostgreSQL</productname>の配布されるソースの中にあるファイル<filename>contrib/start-scripts/linux</filename>の中から起動と終了をランレベルシステムと合わせる方法を探してください。</para>

    </listitem>

    <listitem>
     <para>
      <!-- On <productname>NetBSD</productname>, either use the
      <productname>FreeBSD</productname> or
      <productname>Linux</productname> start scripts, depending on
      preference, as an example and place the file at
      <filename>/usr/local/etc/rc.d/postgresql</filename>. -->

      <productname>NetBSD</productname>では<productname>FreeBSD</productname>か<productname>Linux</productname>の好きな方の起動スクリプトを例として使い、<filename>/usr/local/etc/rc.d/postgresql</filename>に置いてください。<indexterm><primary>PostgreSQL</primary><secondary>NetBSD</secondary></indexterm>

     </para>
    </listitem>

    <listitem>
     <para>
      <!-- On <productname>Solaris</productname>, edit the file
      <filename>rc2.d</filename> to contain the following single line: -->

      <productname>Solaris</productname>では、<filename>rc2.d</filename>ファイルに以下の1行を追加してください。<indexterm><primary>PostgreSQL</primary><secondary>Solaris</secondary></indexterm></para>

<programlisting>
su - postgres -c "/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data"
</programlisting>
    </listitem>
   </itemizedlist>

   <para>
    <!-- While the <application>postmaster</application> is running, its
    PID is in the file <filename>postmaster.pid</filename> in the data
    directory. This is used as an interlock against multiple postmasters
    running in the same data directory, and can also be used for
    shutting down the postmaster. -->

    <application>postmaster</application>が実行している間は、そのPIDはデータディレクトリの中の<filename>postmaster.pid</filename>ファイルに記述されています。これは同じデータディレクトリで動く複数のpostmasterの調整をし、postmasterの終了にも使うことができます。

   </para>

   <sect2 id="postmaster-start-failures">
    <!-- <title>Server Start-up Failures</title> -->
    <title>サーバー起動の失敗</title>
<indexterm><primary>PostgreSQL</primary><secondary sortas="さーばーきどうのしっぱい">サーバー起動の失敗</secondary></indexterm>
    <para>
     <!-- There are several common reasons for the postmaster to fail to
     start up. Check the postmaster's log file, or start it by hand
     (without redirecting standard output or standard error) to see
     what complaint messages appear. Some of the possible error
     messages are reasonably self-explanatory, but here are some that
     are not. -->

     postmasterの起動が失敗する理由として、代表的なものがいくつかあります。postmasterのログファイルをチェックするか、どのようなエラーメッセージが出ているか見るには、（標準出力か標準エラーをリダイレクトせずに）手動で起動してみてください。いくつかのエラーメッセージは比較的原因がわかりやすいものですが、そうではないものについてここで説明します。

    </para>

<screen>
FATAL: StreamServerPort: bind() failed: Address already in use
        Is another postmaster already running on that port?
</screen>
     <!-- This usually means just what it suggests: you accidentally
     started a second postmaster 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 wording, there may be a different problem. For
     example, trying to start a postmaster on a reserved port number
     may draw something like -->

<para>これは多くの場合、すでにpostmasterが動いているポートで2つ目のpostmasterを起動してしまった可能性があることを示しています。しかし、もしカーネルエラーメッセージが<literal>Address already in use</literal>ではない場合や、それに似たようなものだった場合は別の問題の可能性もあります。たとえば、予約済みのポート番号でpostmasterを起動しようとすると下記のようなメッセージが出ます。</para>

<screen>
&gt; <userinput>postmaster -i -p 666</userinput>
FATAL: StreamServerPort: bind() failed: Permission denied
        Is another postmaster already running on that port?
</screen>

    <para>ほかのエラーメッセージも見てみましょう。</para>

     <!-- A message like -->
<screen>
IpcMemoryCreate: shmget(key=5440001, size=83918612, 01600) failed: Invalid argument
FATAL 1:  ShmemCreate: cannot create region
</screen>
     <!-- 
     probably means that your kernel's limit on the size of shared
     memory areas is smaller than the buffer area that Postgres is
     trying to create (83918612 bytes in this example). Or it could
     mean that you don't have System-V-style shared memory support
     configured into your kernel at all. As a temporary workaround,
     you can try starting the postmaster with a smaller-than-normal
     number of buffers (<option>-B</option> switch). You will
     eventually want to reconfigure your kernel to increase the
     allowed shared memory size, however. You may see this message
     when trying to start multiple postmasters on the same machine, if
     their total space requests exceed the kernel limit. -->

<para>上記のようなメッセージが出た場合は、おそらく共有メモリ領域のカーネルの上限がPostgresが作ろうとしているバッファ領域よりも小さい可能性があります（この例では83,918,612バイトです）。または、System V方式の共有メモリサポートがカーネルにまったく設定されていない可能性もあります。一時的な策として、（<option>-B</option>オプションを使用して）postmasterを通常よりも少ないバッファ数で起動することもできます。しかし最終的には、カーネルを再設定し、使用可能共有メモリサイズを増やしたほうがよいでしょう。このメッセージは、同じマシン上で複数のpostmasterを起動させようとするときに要求された空間の合計がカーネルの上限を越えた場合にも表示されます。

    </para>

    <para>
     <!--  An error like -->
     下記のようなエラーはディスクの空き容量がなくなったということを示しているわけでは<emphasis>ありません</emphasis>。</para>

<screen>
IpcSemaphoreCreate: semget(key=5440026, num=16, 01600) failed: No space left on device
</screen>
     <!-- does <emphasis>not</emphasis> mean that you've run out of disk
     space; it means that your kernel's limit on the number of System
     V semaphores is smaller than the number
     <productname>Postgres</productname> wants to create. As above,
     you may be able to work around the problem by starting the
     postmaster with a reduced number of backend processes
     (<option>-N</option> switch), but you'll eventually want to
     increase the kernel limit. -->

<para>これはカーネルのSystem Vセマフォの上限が<productname>Postgres</productname>が作成しようとしている数よりも小さいということを意味しています。上記のように、バックエンドプロセスを減らして（<option>-N</option>オプションを使用して）postmasterを起動させることで問題は回避できるかもしれませんが最終的にはカーネルの設定を変えてセマフォの上限を増やした方がよいでしょう。

    </para>

    <para>
    <!-- 
     If you get an <quote>illegal system call</> error, then it is likely that
     shared memory or semaphores are not supported at all in your kernel. In
     that case your only option is to re-configure the kernel to turn on these
     features. -->

     <quote>illegal system call</>というエラーが表示された場合は、使用しているカーネルでは共有メモリやセマフォがまったくサポートされていない可能性があります。その場合、これらの機能を使えるように設定し直すことが唯一の選択肢となります。

    </para>

    <para>
     <!-- Details about configuring System V IPC facilities are given in
     <xref linkend="sysvipc">. -->

     System V IPC設備の設定についての詳細は<xref linkend="sysvipc">を参照してください。

    </para>
   </sect2>

   <sect2 id="client-connection-problems">
    <!-- <title>Client Connection Problems</title> -->
    <title>クライアント接続の問題</title>
<indexterm><primary>PostgreSQL</primary><secondary sortas="くらいあんとせつぞくのもんだい">クライアント接続の問題</secondary></indexterm>
    <para>
     <!-- 
     Although the possible error conditions on the client side are
     both virtually infinite and application dependent, a few of them
     might be directly related to how the server was started up.
     Conditions other than those shown below should be documented with
     the respective client application. -->

     クライアント側で起こり得るエラー状態はほとんど無限でありアプリケーションに依存します。そのなかのいくつかはサーバーが起動された方法と直接関係するかもしれません。以下で説明する以外の状態については各々のクライアントアプリケーションの資料を参照してください。

    </para>

<screen>
PQconnectPoll() -- connect() failed: Connection refused
	Is the postmaster running (with -i) at 'server.joe.com'
	and accepting connections on TCP/IP port 5432?
</screen>
     <!-- This is the generic <quote>I couldn't find a server to talk
     to</quote> failure. It looks like the above when TCP/IP
     communication is attempted. A common mistake is to forget the
     <option>-i</option> to the postmaster to allow TCP/IP
     connections. -->

<para>これは一般的な<quote>接続するサーバーが見つけられませんでした</quote>という失敗です。TCP/IP通信を試みたときに上記のような表示が出ます。よくある間違いはpostmasterにTCP/IPを許可する<option>-i</option>オプションを付け忘れていることです。

    </para>

    <para>
     <!-- Alternatively, you'll get this when attempting
     Unix-socket communication to a local postmaster: -->
     代わりに、ローカルのpostmasterにUnixソケット通信を試みると下記のような表示が出ます。</para>

<screen>
connectDBstart() -- connect() failed: No such file or directory
	Is the postmaster running locally
	and accepting connections on Unix socket '/tmp/.s.PGSQL.5432'?
</screen>

    <para>
     <!-- 
     The last line is useful in verifying that the client is trying to
     connect where it is supposed to. If there is in fact no
     postmaster running there, the kernel error message will typically
     be either <computeroutput>Connection refused</computeroutput> or
     <computeroutput>No such file or directory</computeroutput>, as
     illustrated. (It is particularly important to realize that
     <computeroutput>Connection refused</computeroutput> in this
     context does <emphasis>not</emphasis> mean that the postmaster
     got your connection request and rejected it __ that case will
     produce a different message, as shown in <xref
     linkend="client-authentication-problems">.) Other error messages
     such as <computeroutput>Connection timed out</computeroutput> may
     indicate more fundamental problems, like lack of network
     connectivity. 
     -->

     最後の行は、クライアントが正しいところに接続しようとしていることを実証するのに役立ちます。もしそこに動いているpostmasterがない場合、典型的なカーネルエラーメッセージは、表示されているように<literal>Connection refused</literal>もしくは<literal>No such file or directory</literal>となります。特にこの場合の<literal>Connection refused</literal>はpostmasterが接続要求を受け付け拒否したわけでは<emphasis>ない</emphasis>ということを理解しておくことが大切です（もしそうだった場合は<xref linkend="client-authentication-problems">で示されるような別のメッセージが表示されます）。<literal>Connection timed out</literal>のような他のメッセージは、たとえばネットワーク接続の欠如のようなもっと根本的な問題を表しています。
    </para>
   </sect2>
  </sect1>

  <sect1 id="runtime-config">
   <!-- <Title>Run-time configuration</Title> -->
   <Title>実行時の設定</Title>
<indexterm><primary>PostgreSQL</primary><secondary sortas="じっこうじのせってい">実行時の設定</secondary></indexterm>
   <para>
    <!-- There are a lot of configuration parameters that affect the
    behavior of the database system in some way or other. Here we
    describe how to set them and the following subsections will
    discuss each of them. -->

    いろいろな意味でデータベースシステムの動作に影響するパラメータの設定はたくさんあります。ここではそれらの設定方法を述べ、後のセクションで1つ1つについて説明します。<indexterm><primary>PostgreSQL</primary><secondary sortas="ぱらめーた">パラメータ</secondary></indexterm>

   </para>

   <para>
    <!-- 
    All parameter names are case-insensitive. Every parameter takes a
    value of one of the four types boolean, integer, floating point,
    string as described below. Boolean values are
    <literal>ON</literal>, <literal>OFF</literal>,
    <literal>TRUE</literal>, <literal>FALSE</literal>,
    <literal>YES</literal>, <literal>NO</literal>,
    <literal>1</literal>, <literal>0</literal> (case-insensitive) or
    any non-ambiguous prefix of these. -->

    すべてのパラメータ名は大文字/小文字を区別しません。それぞれのパラメータは下記で説明するように4つの型、ブーリアン（論理）、整数、浮動小数点、文字列のいずれかの値を持ちます。ブーリアンの値は<literal>ON</literal>、<literal>OFF</literal>、<literal>TRUE</literal>、<literal>FALSE</literal>、<literal>YES</literal>、<literal>NO</literal>、<literal>1</literal>、<literal>0</literal>（大文字/小文字の区別なし）もしくは曖昧でなければこれらの頭文字でも構いません。

   </para>

   <para>
    <!-- One way to set these options is to create a file
    <filename>postgresql.conf</filename> in the data directory (e.g.,
    <filename>/usr/local/pgsql/data</filename>). An example of what
    this file could look like is: -->

    これらのオプションを設定するための1つの方法としては、ファイル<filename>postgresql.conf</filename>をデータディレクトリ（たとえば<filename>/usr/local/pgsql/data</filename>）に作成することがあります。そのファイルがどのようになっているかの例を以下に示します。<indexterm><primary>postgresql.conf</primary></indexterm><indexterm><primary>PostgreSQL</primary><secondary>postgresql.conf</secondary></indexterm></para>

<programlisting>
# This is a comment
log_connections = yes
syslog = 2
</programlisting>
    <!-- 
    As you see, options are one per line. The equal sign between name
    and value is optional. White space is insignificant, blank lines
    are ignored. Hash marks (<quote>#</quote>) introduce comments
    anywhere. -->

<para>オプションは1行につき1つです。名前と値の間のイコール記号はなくても構いません。空白は意味を持たず、空行は無視されます。シャープ記号（<quote>#</quote>）はどこにあってもコメントを意味します。

   </para>

   <para>
    <!-- 
    The configuration file is reread whenever the postmaster receives
    a SIGHUP signal. This signal is also propagated to all running
    backend processes, so that running sessions get the new default.
    Alternatively, you can send the signal to only one backend process
    directly. -->

    この設定ファイルはpostmasterがSIGHUPシグナルを受けるたびに再読み込みされます。また、このシグナルは実行中のセッションが新しいデフォルトを取得するように、すべての稼働中のバックエンドプロセスにも伝えられます。また、シグナルを1つのバックエンドのみに直接送ることもできます。

   </para>

   <para>
    <!-- 
    A second way to set these configuration parameters is to give them
    as a command line option to the postmaster, such as -->

    これらの設定パラメータを指定する2番目の方法として、下記のようにpostmasterにコマンドラインオプションとして渡す方法があります。</para>

<programlisting>
postmaster -c log_connections=yes -c syslog=2
</programlisting>
    <!-- 
    which would have the same effect as the previous example.
    Command-line options override any conflicting settings in
    <filename>postgresql.conf</filename>. -->
<para>これは1つ前の例と同じ結果が得られます。コマンドラインオプションは<filename>postgresql.conf</filename>の中の矛盾する設定を書き換えてしまいます。

   </para>

   <para>
    <!-- 
    Occasionally it is also useful to give a command line option to
    one particular backend session only. The environment variable
    <envar>PGOPTIONS</envar> can be used for this purpose on the
    client side: -->

    コマンドラインオプションを1つの特定のバックエンドセッションのみに渡すことが有用な場合があります。これは下記のように、クライアント側で環境変数<envar>PGOPTIONS</envar>を使用することによって可能となります（これは<application>psql</application>のみならず、あらゆるクライアントアプリケーションで使用することができます）。<indexterm><primary>PGOPTIONS</primary></indexterm><indexterm><primary sortas="かんきょうへんすう">環境変数</primary><secondary>PGOPTIONS</secondary></indexterm></para>

<programlisting>
env PGOPTIONS='-c geqo=off' psql
</programlisting>
    <!-- 
    (This works for any client application, not just
    <application>psql</application>.) Note that this won't work for
    options that are necessarily fixed once the server is started,
    such as the port number. -->


<para>しかし、ポート番号のような、サーバーが起動したときに設定されるオプションでは使用できないので注意してください。
   </para>

   <para>
    <!-- 
    Finally, some options can be changed in individual SQL sessions
    with the <command>SET</command> command, for example -->

    最後に、いくつかのオプションは個別のSQLセッションの中で<command>SET</command>コマンドを使って変えることができます。たとえば下記のようになります。</para>

<screen>
=&gt; <userinput>SET ENABLE_SEQSCAN TO OFF;</userinput>
</screen>
    <!-- 
    See the SQL command language reference for details on the syntax.
    -->

<para>構文の詳細については<citetitle>&reference-guide;</citetitle>にあるSQLコマンドの言語リファレンスを参照してください。
    </para>

   <sect2 id="runtime-config-optimizer">
    <!-- <title>Planner and Optimizer Tuning</title> -->
    <title>プランナとオプティマイザの調整</title>
<indexterm><primary>PostgreSQL</primary><secondary sortas="ぱらめーた">パラメータ</secondary><tertiary sortas="ぷらんなとおぷてぃまいざ">プランナとオプティマイザ</tertiary></indexterm>
    <variablelist>
     <varlistentry>
      <term>CPU_INDEX_TUPLE_COST（<type><!--floating point-->浮動小数点</type>）</term>
      <listitem>
       <para>
        <!-- 
        Sets the query optimizer's estimate of the cost of processing
	each index tuple during an index scan. This is measured as a
	fraction of the cost of a sequential page fetch. -->

        問い合わせオプティマイザがインデックススキャンの間にそれぞれのインデックスタプルを処理するコストの概算を設定します。これは順ページ取り出しのコストとの比率で評価されます。

       </para>
      </listitem>
     </varlistentry>
    
     <varlistentry>
      <!-- <term>CPU_OPERATOR_COST (<type>floating point</type>)</term> -->
      <term>CPU_OPERATOR_COST（<type>浮動小数点</type>）</term>
      <listitem>
       <para>
        <!-- Sets the optimizer's estimate of the cost of processing each
	operator in a WHERE clause. This is measured as a fraction of
	the cost of a sequential page fetch. -->

        オプティマイザがWHERE句の中のそれぞれの演算子を処理するコストの概算を設定します。これは順ページ取り出しのコストとの比率で評価されます。
       </para>
      </listitem>
     </varlistentry>
    
     <varlistentry>
      <!-- <term>CPU_TUPLE_COST (<type>floating point</type>)</term> -->
      <term>CPU_TUPLE_COST（<type>浮動小数点</type>）</term>
      <listitem>
       <para>
        <!-- Sets the query optimizer's estimate of the cost of processing
	each tuple during a query. This is measured as a fraction of
	the cost of a sequential page fetch. -->

        問い合わせオプティマイザが問い合わせの間にそれぞれのタプルを処理するコストを設定します。これは順ページ取り出しのコストとの比率で評価されます。

       </para>
      </listitem>
     </varlistentry>
    
     <varlistentry>
      <!-- <term>EFFECTIVE_CACHE_SIZE (<type>floating point</type>)</term>-->
      <term>EFFECTIVE_CACHE_SIZE（<type>浮動小数点</type>）</term>
      <listitem>
       <para>
        <!-- Sets the optimizer's assumption about the effective size of
	the disk cache (that is, the portion of the kernel's disk
	cache that will be used for
	<productname>Postgres</productname> data files). This is
	measured in disk pages, which are normally 8kB apiece. -->

        ディスクキャッシュの実効サイズに関するオプティマイザの推測を設定します（すなわち、<productname>Postgres</productname>データファイルに使われるカーネルのディスクキャッシュです）。これは、通常は一単位8Kバイトのディスクページを基準に評価します。
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>ENABLE_HASHJOIN (<type>boolean</type>)</term> -->
      <term>ENABLE_HASHJOIN（<type>ブーリアン</type>）</term>
      <listitem>
       <para>
        <!-- Enables or disables the query planner's use of hash-join plan
        types. The default is on. This is mostly useful to debug the
        query planner. -->

        問い合わせプランナのハッシュ結合型のプランの使用を有効または無効にします。デフォルトでは有効です。これは問い合わせプランナのデバッグで役に立ちます。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>ENABLE_INDEXSCAN (<type>boolean</type>)</term> -->
      <term>ENABLE_INDEXSCAN（<type>ブーリアン</type>）</term>
      <listitem>
       <para>
        <!-- Enables or disables the query planner's use of index scan plan
        types. The default is on. This is mostly useful to debug the
        query planner. -->

        問い合わせプランナのインデックススキャン型のプランの使用を有効または無効にします。デフォルトでは有効です。これは問い合わせプランナのデバッグで役に立ちます。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>ENABLE_MERGEJOIN (<type>boolean</type>)</term> -->
      <term>ENABLE_MERGEJOIN（<type>ブーリアン</type>）</term>
      <listitem>
       <para>
        <!-- Enables or disables the query planner's use of merge-join plan
        types. The default is on. This is mostly useful to debug the
        query planner. -->
        
        問い合わせプランナのマージ結合型のプランの使用を有効または無効にします。デフォルトでは有効です。これは問い合わせプランナのデバッグで役に立ちます。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>ENABLE_NESTLOOP (<type>boolean</type>)</term> -->
      <term>ENABLE_NESTLOOP（<type>ブーリアン</type>）</term>
      <listitem>
       <para>
        <!-- Enables or disables the query planner's use of nested-loop
	join plans. It's not possible to suppress nested-loop joins
	entirely, but turning this variable off discourages the
	planner from using one if there is any other method available.
	The default is on. This is mostly useful to debug the query
	planner. -->

        問い合わせプランナのネストループ結合計画の使用を有効または無効にします。ネストループ結合を完全に抑えることは不可能ですが、この変数を無効にすることにより他の方法がある場合、プランナがネストループ結合を使わないようにします。デフォルトでは有効です。これは問い合わせプランナのデバッグで役に立ちます。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>ENABLE_SEQSCAN (<type>boolean</type>)</term> -->
      <term>ENABLE_SEQSCAN（<type>ブーリアン</type>）</term>
      <listitem>
       <para>
       <!-- 
        Enables or disables the query planner's use of sequential scan
	plan types. It's not possible to suppress sequential scans
	entirely, but turning this variable off discourages the
	planner from using one if there is any other method available.
	The default is on. This is mostly useful to debug the query
	planner. -->

        問い合わせプランナが順スキャン型のプランの使用を有効または無効にします。順スキャンを完全に抑えることは不可能ですが、この変数を無効にすることにより他の方法がある場合、プランナが順スキャンを使わないようにします。デフォルトでは有効です。これは問い合わせプランナのデバッグで役に立ちます。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>ENABLE_SORT (<type>boolean</type>)</term> -->
      <term>ENABLE_SORT（<type>ブーリアン</type>）</term>
      <listitem>
       <para>
        <!-- Enables or disables the query planner's use of explicit sort
	steps. It's not possible to suppress explicit sorts entirely,
	but turning this variable off discourages the planner from
	using one if there is any other method available. The default
	is on. This is mostly useful to debug the query planner. -->

        問い合わせプランナが明示的なソート処理の使用を有効または無効にします。明白なソートを完全に抑えることは不可能ですが、この変数を無効にすることにより他のメソッドがある場合、プランナが順スキャンを使わないようにします。デフォルトでは有効です。これは問い合わせプランナのデバッグで役に立ちます。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>ENABLE_TIDSCAN (<type>boolean</type>)</term> -->
      <term>ENABLE_TIDSCAN（<type>ブーリアン</type>）</term>
      <listitem>
       <para>
        <!-- Enables or disables the query planner's use of TID scan plan
        types. The default is on. This is mostly useful to debug the
        query planner. -->

        問い合わせプランナがTIDスキャン計画の型の使用を有効または無効にします。デフォルトでは有効です。これは問い合わせプランナのデバッグで役に立ちます。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>GEQO (<type>boolean</type>)</term> -->
      <term>GEQO（<type>ブーリアン</type>）</term>
      <listitem>
       <para>
        <!-- Enables or disables genetic query optimization, which is an
        algorithm that attempts to do query planning without
        exhaustive search. This is on by default. See also the various
        other GEQO_ settings. -->

        問い合わせプランナが、しらみつぶしの検索を行うことなく問い合わせ計画を作成するアルゴリズムである遺伝的問い合わせ最適化の使用を有効または無効にします。デフォルトは有効です。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>GEQO_EFFORT (<type>integer</type>)</term>
      <term>GEQO_GENERATIONS (<type>integer</type>)</term>
      <term>GEQO_POOL_SIZE (<type>integer</type>)</term>
      <term>GEQO_RANDOM_SEED (<type>integer</type>)</term>
      <term>GEQO_SELECTION_BIAS (<type>floating point</type>)</term> -->

      <term>GEQO_EFFORT（<type>整数</type>）</term>
      <term>GEQO_GENERATIONS（<type>整数</type>）</term>
      <term>GEQO_POOL_SIZE（<type>整数</type>）</term>
      <term>GEQO_RANDOM_SEED（<type>整数</type>）</term>
      <term>GEQO_SELECTION_BIAS（<type>浮動小数点</type>）</term>

      <listitem>
       <para>
        <!-- Various tuning parameters for the genetic query optimization
        algorithm: The pool size is the number of individuals in one
        population. Valid values are between 128 and 1024. If it is
        set to 0 (the default) a pool size of 2^(QS+1), where QS
        is the number of FROM items in the query, is taken. The effort
        is used to calculate a default for generations. Valid values
        are between 1 and 80, 40 being the default. Generations
        specifies the number of iterations in the algorithm. The
        number must be a positive integer. If 0 is specified then
        Effort * Log2(PoolSize) is used. The run time of the algorithm
        is roughly proportional to the sum of pool size and
        generations. The selection bias is the selective pressure
        within the population. Values can be from 1.50 to 2.00; the
        latter is the default. The random seed can be set to get
        reproduceable results from the algorithm. If it is set to -1
        then the algorithm behaves non-deterministically. -->

        遺伝的問い合わせ最適化のアルゴリズムにはさまざまなパラメータがあります。プールのサイズは1つの個体群の個体の数です。有効な値は128から1,024までです。もし0に設定されると（デフォルトです）、QSが問い合わせの中のFROM句の数である2^(QS+1)のプールサイズが選ばれます。これは世代のデフォルトを計算するために行われます。固定値は1から80の間で、デフォルトは40です。世代はアルゴリズム中の反復の数を指定します。その数は正の整数でなくてはいけません。もし0が指定された場合、Effort * Log2(PoolSize)が使われます。そのアルゴリズムの実行時間は、大雑把にいえばプールサイズと世代の合計と同じです。この選択の偏りは個体群の中の選択圧力です。値は1.5から2.00の間で、2.00がデフォルトです。アルゴリズムから再現可能な結果を得るために乱数シードを設定することができます。もし-1に設定されるとアルゴリズムは非決定論的に動作します。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>GEQO_THRESHOLD (<type>integer</type>)</term> -->
      <term>GEQO_THRESHOLD（<type>整数</type>）</term>
      <listitem>
       <para>
        <!-- Use genetic query optimization to plan queries with at least
        this many FROM items involved.  (Note that a JOIN construct
	counts as only one FROM item.) The default is 11. For simpler
	queries it is usually best to use the
        deterministic, exhaustive planner. -->

        少なくともこれだけの数のFROM句の項目含む問い合わせを計画する場合には、遺伝的問い合わせ最適化を使うべきです（JOIN構造体は1つのFROM句として数えられます）。デフォルトは11です。もっと単純な問い合わせでは、決定論的でしらみつぶし検索プランナを使うのが最適でしょう。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>KSQO (<type>boolean</type>)</term> -->
      <term>KSQO（<type>ブーリアン</type>）</term>
      <listitem>
       <para>
        <!-- The <firstterm>Key Set Query Optimizer</firstterm>
        (<abbrev>KSQO</abbrev>) causes the query planner to convert
        queries whose WHERE clause contains many OR'ed AND clauses
        (such as <literal>WHERE (a=1 AND b=2) OR (a=2 AND b=3)
        ...</literal>) into a UNION query. This method can be faster
        than the default implementation, but it doesn't necessarily
        give exactly the same results, since UNION implicitly adds a
        SELECT DISTINCT clause to eliminate identical output rows.
        KSQO is commonly used when working with products like
        <productname>Microsoft Access</productname>, which tend to
        generate queries of this form. -->

        <firstterm>キーセット問い合わせオプティマイザ</firstterm>（<abbrev>KSQO</abbrev>）は、問い合わせプランナに、WHERE句にたくさんのORがついたAND句を持つ（たとえば<literal>WHERE (a=1 AND b=2) OR  (a=2 AND b=3) ...</literal>）問い合わせをUNION文に変換させます。このメソッドはデフォルト実装よりも速くできますが、UNIONは同一出力行を削除するために暗黙的にSELECT DISTINCT句を追加するため、必ずしも同じ結果にはなりません。KSQOは一般的に<productname>Microsoft Access</productname>のような、こういった形式の問い合わせをよく使う製品の作業で使われます。<indexterm><primary sortas="きーせっとといあわせおぷてぃまいざ">キーセット問い合わせオプティマイザ</primary></indexterm><indexterm><primary>KSQO</primary></indexterm><indexterm><primary>PostgreSQL</primary><secondary sortas="きーせっとといあわせおぷてぃまいざ">キーセット問い合わせオプティマイザ</secondary></indexterm><indexterm><primary>PostgreSQL</primary><secondary>KSQO</secondary></indexterm>

       </para>

       <para>
       <!-- 
        The KSQO algorithm used to be absolutely essential for queries
        with many OR'ed AND clauses, but in
        <productname>Postgres</productname> 7.0 and later the standard
        planner handles these queries fairly successfully. Hence the
        default is OFF. -->

        KSQOアルゴリズムは、たくさんのORがついたAND句ではかつては必須でしたが、<productname>Postgres</productname> 7.0以降では標準プランナがこれらの問い合わせをかなり上手に処理します。したがってデフォルトでは無効です。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>RANDOM_PAGE_COST (<type>floating point</type>)</term> -->
      <term>RANDOM_PAGE_COST（<type>浮動小数点</type>）</term>
      <listitem>
       <para>
        <!-- Sets the query optimizer's estimate of the cost of a
	nonsequentially fetched disk page. This is measured as a
	multiple of the cost of a sequential page fetch. -->

        問い合わせオプティマイザの順不同に取りだされたディスクページのコストの概算を設定します。これは順ページ取り出しの倍数で評価されます。

       </para>
      </listitem>
     </varlistentry>
    </variablelist>

   <note>
    <para>
     <!-- Unfortunately, there is no well-defined method of determining
     ideal values for the family of <quote>COST</quote> variables that
     were just described. You are encouraged to experiment and share
     your findings. -->

     残念なことに、上記で説明された<quote>COST</quote>変数のファミリーの理想的な値を決定するきっちりと決められた方法はありません。実験してみてよい方法があったら教えてください。
 
    </para>
   </note>

   </sect2>

   <sect2 id="logging">
    <!-- <title>Logging and Debugging</title> -->
    <title>ログとデバッグ</title>
<indexterm><primary sortas="ろぐ">ログ</primary></indexterm>
<indexterm><primary>PostgreSQL</primary><secondary sortas="ろぐ">ログ</secondary></indexterm>
<indexterm><primary sortas="でばっぐ">デバッグ</primary></indexterm>
<indexterm><primary>PostgreSQL</primary><secondary sortas="でばっぐ">デバッグ</secondary></indexterm>
<indexterm><primary>PostgreSQL</primary><secondary sortas="ぱらめーた">パラメータ</secondary><tertiary sortas="ろぐ">ログ</tertiary></indexterm>
<indexterm><primary>PostgreSQL</primary><secondary sortas="ぱらめーた">パラメータ</secondary><tertiary sortas="でばっぐ">デバッグ</tertiary></indexterm>
    <variablelist>
     <varlistentry>
      <!-- <term>DEBUG_ASSERTIONS (<type>boolean</type>)</term> -->
      <term>DEBUG_ASSERTIONS（<type>ブーリアン</type>）</term>
      <listitem>
       <para>

        <!-- 
        Turns on various assertion checks. This is a debugging aid. If
        you are experiencing strange problems or crashes you might
        want to turn this on, as it might expose programming mistakes.
        To use this option, the macro <literal>USE_ASSERT_CHECKING</literal>
        must be defined when Postgres is built (see the configure option
	<literal>__enable-cassert</literal>).  Note that
	<literal>DEBUG_ASSERTIONS</literal> defaults to ON if Postgres
	has been built this way. -->

        さまざまな表明（assert）のチェックを有効にします。これはデバッグ用の道具です。もし問題やクラッシュがある場合は有効にすると、プログラムの間違いが明らかになるかもしれません。このオプションを使うためには、Postgresを構築するときにマクロ<literal>USE_ASSERT_CHECKING</literal>が定義されていなければいけません（<literal>--enable-cassert</literal>の設定オプションを見てください）。Postgresをそのように構築すると<literal>DEBUG_ASSERTIONS</literal>はデフォルトでは有効になります。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>DEBUG_LEVEL (<type>integer</type>)</term> -->
      <term>DEBUG_LEVEL（<type>整数</type>）</term>
      <listitem>
       <para>
        <!-- The higher this value is set, the more
        <quote>debugging</quote> output of various sorts is generated
        in the server log during operation. This option is 0 by
        default, which means no debugging output. Values up to about 4
        currently make sense. -->

        この値が高く設定されるほど、演算中にサーバーログでさまざまな<quote>デバッグ</quote>用表示が行われます。このオプションはデフォルトでは0で、これはデバッグ用表示なしです。現在では4までの値しか意味がありません。
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>DEBUG_PRINT_PARSE (<type>boolean</type>)</term>
      <term>DEBUG_PRINT_PLAN (<type>boolean</type>)</term>
      <term>DEBUG_PRINT_REWRITTEN (<type>boolean</type>)</term>
      <term>DEBUG_PRINT_QUERY (<type>boolean</type>)</term>
      <term>DEBUG_PRETTY_PRINT (<type>boolean</type>)</term> -->

      <term>DEBUG_PRINT_PARSE（<type>ブーリアン</type>）</term>
      <term>DEBUG_PRINT_PLAN（<type>ブーリアン</type>）</term>
      <term>DEBUG_PRINT_REWRITTEN（<type>ブーリアン</type>）</term>
      <term>DEBUG_PRINT_QUERY（<type>ブーリアン</type>）</term>
      <term>DEBUG_PRETTY_PRINT（<type>ブーリアン</type>）</term>

      <listitem>
       <para>
        <!-- For any executed query, prints either the query, the parse
        tree, the execution plan, or the query rewriter output to the
        server log. <option>DEBUG_PRETTY_PRINT</option> selects are
        nicer but longer output format.-->

        実行されたどのような問い合わせに対しても、問い合わせ、構文解析ツリー、実行プラン、もしくは問い合わせ書き換えの出力のいずれかをサーバーログに表示します。<option>DEBUG_PRETTY_PRINT</option>選択の方がよいですが、出力形式が長くなります。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>HOSTNAME_LOOKUP (<type>boolean</type>)</term> -->
      <term>HOSTNAME_LOOKUP（<type>ブーリアン</type>）</term>
      <listitem>
       <para>
        <!-- By default, connection logs only show the IP address of the
        connecting host. If you want it to show the host name you can
        turn this on, but depending on your host name resolution setup
        it might impose a non-negligible performance penalty. This
        option can only be set at server start. -->

        デフォルトでは、接続ログはホストのIPアドレスのみを表示します。もしホスト名を表示させたい場合はこれを有効にしますが、ホスト名解決の設定によっては無視できないほどの性能の低下をもたらすこともあります。このオプションはサーバー起動時にのみ設定できます。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>LOG_CONNECTIONS (<type>boolean</type>)</term> -->
      <term>LOG_CONNECTIONS（<type>ブーリアン</type>）</term>
      <listitem>
       <para>
        <!-- Prints a line informing about each successful connection to
        the server log. This is off by default, although it is
        probably very useful. This option can only be set at server
        start. -->

       成功した接続を知らせる行をサーバーログに表示します。デフォルトでは無効ですが、これはとても役に立ちます。このオプションはサーバー起動時にのみ設定できます。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>LOG_PID (<type>boolean</type>)</term> -->
      <term>LOG_PID（<type>ブーリアン</type>）</term>
      <listitem>
       <para>
       <!--  
        Prefixes each server log message with the process id of the
        backend process. This is useful to sort out which messages
        pertain to which connection. The default is off. -->

        それぞれのサーバーログメッセージの冒頭にバックエンドプロセスのプロセスIDを付けます。これは、どのメッセージがどの接続に属しているかをはっきりするのに役立ちます。デフォルトでは無効です。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>LOG_TIMESTAMP (<type>boolean</type>)</term> -->
      <term>LOG_TIMESTAMP（<type>ブーリアン</type>）</term>
      <listitem>
       <para>
        <!-- Prefixes each server log message with a timestamp. The default
        is off. -->

        それぞれのサーバーログメッセージの先頭にタイムスタンプを付けます。デフォルトでは無効です。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>SHOW_QUERY_STATS (<type>boolean</type>)</term>
      <term>SHOW_PARSER_STATS (<type>boolean</type>)</term>
      <term>SHOW_PLANNER_STATS (<type>boolean</type>)</term>
      <term>SHOW_EXECUTOR_STATS (<type>boolean</type>)</term> -->

      <term>SHOW_QUERY_STATS（<type>ブーリアン</type>）</term>
      <term>SHOW_PARSER_STATS（<type>ブーリアン</type>）</term>
      <term>SHOW_PLANNER_STATS（<type>ブーリアン</type>）</term>
      <term>SHOW_EXECUTOR_STATS（<type>ブーリアン</type>）</term>

      <listitem>
       <para>
        <!-- For each query, write performance statistics of the respective
        module to the server log. This is a crude profiling
        instrument. -->

        それぞれの問い合わせに対し、各々の性能統計値をサーバーログに書き出します。これは粗野なプロファイルの道具です。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>SHOW_SOURCE_PORT (<type>boolean</type>)</term> -->
      <term>SHOW_SOURCE_PORT（<type>ブーリアン</type>）</term>
      <listitem>
       <para>
        <!-- 
        Shows the outgoing port number of the connecting host in the
        connection log messages. You could trace back the port number
        to find out what user initiated the connection. Other than
        that it's pretty useless and therefore off by default. This
        option can only be set at server start. -->

        接続ログメッセージの中で接続するホストのポート番号を表示します。どのユーザーが接続を開始したかを調べるためにポート番号を使うことができます。それ以外では特に役に立たないのでデフォルトでは無効になっています。このオプションはサーバー起動時にのみ設定することができます。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>SYSLOG (<type>integer</type>)</term> -->
      <term>SYSLOG（<type>整数</type>）</term>
      <listitem>
       <para>
        <!-- <productname>Postgres</productname> allows the use of
        <application>syslog</application> for logging. If this option
        is set to 1, messages go both to syslog and the standard
        output. A setting of 2 sends output only to syslog. (Some
        messages will still go to the standard output/error.) The
        default is 0, which means syslog is off. This option must be
        set at server start. -->

        <productname>Postgres</productname>は、ログのために<application>syslog</application>を使うことができます。もしこのオプションが1に設定されていると、メッセージはsyslogと標準出力の両方に表示されます。2の設定はsyslogのみに表示されます（標準エラー出力に表示されるメッセージもいくつかあります）。デフォルトでは0ですが、これはsyslogが無効ということです。このオプションはサーバーの起動時に設定されなくてはいけません。

       </para>
       <para>
        <!-- To use syslog, the build of
        <productname>Postgres</productname> must be configured with
        the <option>__enable-syslog</option> option. -->

        syslogを使うためには<productname>Postgres</productname>ののビルドがオプション<option>--enable-syslog</option>で設定されていなくてはいけません。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>SYSLOG_FACILITY (<type>string</type>)</term> -->
      <term>SYSLOG_FACILITY（<type>文字列</type>）</term>
       <listitem>
        <para>
          <!-- This option determines the <application>syslog</application>
          <quote>facility</quote> to be used when syslog is enabled.
          You may choose from LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4,
          LOCAL5, LOCAL6, LOCAL7; the default is LOCAL0.  See also the
          documentation of your system's
          <application>syslog</application>. -->

          このオプションはsyslogが有効なときに<application>syslog</application><quote>ファシリティ</quote>を使うようにします。LOCAL0、LOCAL1、LOCAL2、LOCAL3、LOCAL4、LOCAL5、LOCAL6、LOCAL7の中から選ぶことができ、デフォルトはLOCAL0です。使用しているシステムの<application>syslog</application>ドキュメントも参照してください。

        </para>
       </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>SYSLOG_IDENT (<type>string</type>)</term> -->
      <term>SYSLOG_IDENT（<type>文字列</type>）</term>
       <listitem>
        <para>
         <!-- If logging to syslog is enabled, this option determines the
         program name used to identify
         <productname>PostgreSQL</productname> messages in
         <application>syslog</application> log messages.  The default
         is <quote>postgres</quote>. -->

         このオプションは、syslogのログが有効な場合に<application>syslog</application>ログメッセージの中の<productname>PostgreSQL</productname>メッセージを識別するために使われるプログラム名を指定します。デフォルトは<quote>postgres</quote>です。

        </para>
       </listitem>
      </varlistentry>

     <varlistentry>
      <!-- <term>TRACE_NOTIFY (<type>boolean</type>)</term> -->
      <term>TRACE_NOTIFY（<type>ブーリアン</type>）</term>
      <listitem>
       <para>
        <!-- Generates a great amount of debugging output for the
        <command>LISTEN</command> and <command>NOTIFY</command>
        commands. -->

        コマンド<command>LISTEN</command>と<command>NOTIFY</command>のための大量なデバッグ表示をさせます。

       </para>
      </listitem>
     </varlistentry>
    </variablelist>
   </sect2>

   <sect2 id="runtime-config-general">
    <!-- <title>General operation</title> -->
    <title>全般的な操作</title>
<indexterm><primary>PostgreSQL</primary><secondary sortas="ぱらめーた">パラメータ</secondary><tertiary sortas="ぜんぱん">全般</tertiary></indexterm>
    <variablelist>
     <varlistentry>
      <!-- <term>DEADLOCK_TIMEOUT (<type>integer</type>)</term> -->
      <term>DEADLOCK_TIMEOUT（<type>整数</type>）</term>
      <listitem>
       <para>
        <!-- 
        This is the amount of time, in milliseconds, to wait on a lock
	before checking to see if there is a deadlock condition or not.
	The check for deadlock is relatively slow, so we don't want to
	run it every time we wait for a lock.  We (optimistically?)
	assume that deadlocks are not common in production applications,
	and just wait on the lock for awhile before starting to ask
	questions about whether it can ever get unlocked.
	Increasing this value reduces the amount of time wasted in
	needless deadlock checks, but slows down reporting of real deadlock
	errors.  The default is 1000 (i.e., one second), which is probably
	about the smallest value you would want in practice.  On a heavily
	loaded server you might want to raise it.  Ideally the setting
	should exceed your typical transaction time, so as to improve the
	odds that the lock will be released before the waiter decides to
	check for deadlock. 
	This option can only be set at server start. -->
 
        これは、デッドロック状態があるかどうかを調べるためにロック待ち時間をミリ秒で計算したものです。デッドロックのチェックは比較的遅いので、ロックを待つたびには実行したくありません。（楽天的ですが）デッドロックは一般的な製品アプリケーションには使われていないと仮定し、ロック解除をするかどうか調べる前に単にロック待ちします。この値を増やすことにより必要のないデッドロックのチェックで無駄にされる時間は減りますが、本当にデッドロックがあった場合の報告が遅れます。デフォルトは1000（つまり1秒）で、おそらく実用の際にはこれ以上は必要でしょう。負荷の大きいサーバーではもっと必要かもしれません。理想としてはこの設定は通常のトランザクションにかかる時間を越えているべきです。そうすればロック待ちトランザクションがデッドロックのチェックをする前にロックが解除される可能性が改善されます。このオプションはサーバー起動時にのみ設定できます。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>FSYNC (<type>boolean</type>)</term>-->
      <term>FSYNC（<type>ブーリアン</type>）</term>
      <listitem>
       <para>
        <!-- If this option is on, the <productname>Postgres</> backend
        will use the <function>fsync()</> system call in several
        places to make sure that updates are physically written to
        disk and do not hang around in the kernel buffer cache. This
        increases the chance that a database installation will still
        be usable after an operating system or hardware crash by a
        large amount. (Crashes of the database server itself do
        <emphasis>not</> affect this consideration.) -->

        このオプションを有効にすると、<productname>Postgres</>バックエンドがいくつかの場所で<function>fsync()</>システム呼び出しを使い、更新が物理的にディスクに書き込まれカーネルバッファキャッシュ内に残っていないことを確認します。これはオペレーティングシステムかハードウェアクラッシュの後でもデータベースインストールが使える可能性を大いに高くします（データベースサーバー自体のクラッシュは考慮<emphasis>されません</>）。


       </para>

       <para>
        <!-- 
        However, this operation slows down <productname>Postgres</>,
	because at all those points it has
        to block and wait for the operating system to flush the
        buffers. Without <function>fsync</>, the operating system is
        allowed to do its best in buffering, sorting, and delaying
        writes, which can make for a considerable perfomance
        increase. 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. -->

        しかし、このような操作は、いろいろな場所でオペレーティングシステムがバッファをフラッシュするのを待つためにブロックすることになり、<productname>Postgres</>の動作が遅くなります。<function>fsync</>なしだと、オペレーティングシステムはバッファリング、ソート、そして遅延書き込みを最高の状態で実行することができ、性能が大きく向上します。しかし、もしシステムがクラッシュすると、コミットされたトランザクションの最後のいくつかは一部または全部なくなる可能性もあります。最悪の場合、データが復旧できなくなることもあります。


       </para>

       <para>
        <!-- This option is the subject of an eternal debate in the
        <productname>Postgres</> user and developer communities. Some
        always leave it off, some turn it off only for bulk loads,
        where there is a clear restart point if something goes wrong,
        some leave it on just to be on the safe side. Because it is
        the safe side, on is also the default. If you trust your
        operating system, your hardware, and your utility company (or
	better your UPS), you might want to disable fsync. -->

        このオプションは、<productname>Postgres</>ユーザーと開発者のコミュニティでの永遠の議論となっています。常に無効にする人もいれば、問題が起こったときに必ず再実行できるという前堤で大容量データのロードするときだけ無効にする人もいます。安全を重視するために有効のままにする人もいます。そのほうが確実なので、PostgreSQLでもデフォルトでは有効になっています。もし使っているオペレーティングシステム、ハードウェア、そして付属設備（UPSならもっといいのですが）を信頼するならば、fsyncを無効にしたほうがよいかもしれません。

       </para>

       <para>
        <!-- It should be noted that the performance penalty from doing
	fsyncs is considerably less in <productname>Postgres</> version
	7.1 than it was in prior releases.  If you previously suppressed
	fsyncs because of performance problems, you may wish to reconsider
	your choice. -->

        <productname>Postgres</>バージョン7.1では、fsyncを実行した場合の性能の低下は、以前のリリースと比べてとても小さくなりました。もし性能の問題でfsyncをやめていた場合は、もう一度確認したほうがよいでしょう。

       </para>

       <para>
	<!-- This option can only be set at server start or in the
	<filename>postgresql.conf</filename> file. -->

        このオプションは、サーバー起動時かファイル
        <filename>postgresql.conf</filename>でのみ設定できます。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>KRB_SERVER_KEYFILE (<type>string</type>)</term> -->
      <term>KRB_SERVER_KEYFILE（<type>文字列</type>）</term>
      <listitem>
       <para>
        <!-- Sets the location of the Kerberos server key file. See
        <xref linkend="kerberos-auth"> for details. -->

        Kerberosのサーバーキーファイルの場所を設定します。詳細は
        <xref linkend="kerberos-auth">を参照してください。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>MAX_CONNECTIONS (<type>integer</type>)</term> -->
      <term>MAX_CONNECTIONS（<type>整数</type>）</term>
      <listitem>
       <para>
        <!-- 
        Determines how many concurrent connections the database server
        will allow. The default is 32. There is also a compiled-in
        hard upper limit on this value, which is typically 1024
	(both numbers can be altered when compiling the server). This
        parameter can only be set at server start. -->

        データベースサーバーがいくつの同時接続を許可するかを決定します。デフォルトでは32です。この値にはコンパイルされた上限もあり、通常は1024です（どちらの数字もサーバーをコンパイルするときに変えることができます）。このパラメータはサーバー起動時にのみ設定することができます。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>MAX_EXPR_DEPTH (<type>integer</type>)</term> -->
      <term>MAX_EXPR_DEPTH（<type>整数</type>）</term>
      <listitem>
       <para>
        <!--    
        Sets the maximum expression nesting depth that the parser will
	accept. The default value is high enough for any normal query,
	but you can raise it if you need to. (But if you raise it too
	high, you run the risk of backend crashes due to stack
	overflow.) -->

        パーサーが受け入れる式のネストの深さの最大を設定します。デフォルトの値は通常の問い合わせでは十分ですが、必要があれば上げてください（しかし高くしすぎると、スタックオーバーフローによるバックエンドクラッシュの危険性があります）。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>PORT (<type>integer</type>)</term> -->
      <term>PORT（<type>整数</type>）</term>
      <listitem>
       <para>
        <!-- The TCP port the server listens on; 5432 by default. This
        option can only be set at server start. -->

        サーバーが監視するTCPポートデフォルトでは5432です。このオプションはサーバー起動時にのみ設定できます。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>SHARED_BUFFERS (<type>integer</type>)</term> -->
      <term>SHARED_BUFFERS（<type>整数</type>）</term>
      <listitem>
       <para>
        <!-- Sets the number of shared memory buffers the database server
        will use. The default is 64. Each buffer is typically 8192
        bytes. This option can only be set at server start. -->

        データベースサーバーが使う共有メモリバッファの数を設定します。デフォルトでは64です。それぞれのバッファは通常8,192バイトです。このオプションはサーバー起動時にのみ設定できます。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>SILENT_MODE (<type>bool</type>)</term> -->
      <term>SILENT_MODE（<type>ブーリアン</type>）</term>
      <listitem>
       <para>
        <!-- Runs postmaster silently. If this option is set, postmaster
        will automatically run in background and any controlling ttys
        are disassociated, thus no messages are written to stdout or
        stderr (same effect as postmaster's -S option). Unless some
        logging system such as syslog is enabled, using this option is
        discouraged since it makes it impossible to see error
        messages. -->

        postmasterを「寡黙に」起動します。このオプションが有効にされるとpostmasterが自動的にバックグラウンドで動き、制御端末が切り離されます。したがって、標準出力にも標準エラー出力にもメッセージは表示されなくなります（postmasterの-Sオプションと同じ結果です）。エラーメッセージが見えなくなるので、syslogなどのログシステムが有効でない限りこのオプションは使わないほうがよいでしょう。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>SORT_MEM (<type>integer</type>)</term> -->
      <term>SORT_MEM（<type>整数</type>）</term>
      <listitem>
       <para>
        <!-- 
	Specifies the amount of memory to be used by internal sorts
	and hashes before resorting to temporary disk files. The value
	is specified in kilobytes, and defaults to 512 kilobytes. Note
	that for a complex query, several sorts and/or hashes might be
	running in parallel, and each one will be allowed to use as
	much memory as this value specifies before it starts to put
	data into temporary files.  And don't forget that each running
	backend could be doing one or more sorts.  So the total memory
	space needed could be many times the value of SORT_MEM. -->

        一時ディスクファイルの使用をできるだけ避けるために内部ソートとハッシュで使われるメモリの量を指定します。値はKバイトで指定され、デフォルトは512Kバイトです。複雑な問い合わせでは、いくつかのソートかハッシュが並行して実行される可能性があり、その場合それぞれがデータを一時ファイルに書き出す前にこの値が指定した量のメモリを使うことが許されます。さらにそれぞれの動いているバックエンドが1つ以上のソートをしている可能性があることを忘れないでください。したがって必要なメモリ空間の合計はSORT_MEMの値の何倍にもなり得ます。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>SQL_INHERITANCE (<type>bool</type>)</term> -->
      <term>SQL_INHERITANCE（<type>ブーリアン</type>）</term>
      <listitem>
       <para>
        <!-- 
        This controls the inheritance semantics, in particular whether
        subtables are included into the consideration of various
        commands by default. This was not the case in versions prior
        to 7.1. If you need the old behaviour you can set this
        variable to off, but in the long run you are encouraged to
        change your applications to use the <literal>ONLY</literal>
        keyword to exclude subtables. See the SQL language reference
        and the <citetitle>User's Guide</citetitle> for more
        information about inheritance. -->

        これは継承の意味、特にサブテーブルがさまざまなコマンドにデフォルトで含まれているかどうか、をコントロールします。7.1以前のバージョンではそうではありませんでした。もし古いバージョンの動作をさせたい場合はこの変数を無効にできますが、長い目で見ればアプリケーションがサブテーブルを排除するために<literal>ONLY</literal>キーワードを使うようにするほうがよいでしょう。さらに詳しい継承の情報についてはSQL言語リファレンスと<citetitle>&user-guide;</citetitle>を参照してください。
 
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>SSL (<type>boolean</type>)</term> -->
      <term>SSL（<type>ブーリアン</type>）</term>
      <listitem>
       <para>
        <!-- Enables <acronym>SSL</> connections. Please read
        <xref linkend="ssl-tcp"> before using this. The default
        is off. -->

        <acronym>SSL</>接続を可能にします。これを使う前に<xref linkend="ssl-tcp">を参照してください。デフォルトでは無効です。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>TCPIP_SOCKET (<type>boolean</type>)</term> -->
      <term>TCPIP_SOCKET（<type>ブーリアン</type>）</term>
      <listitem>
       <para>
        <!-- If this is true, then the server will accept TCP/IP
        connections. Otherwise only local Unix domain socket
        connections are accepted. It is off by default. This option
        can only be set at server start. -->

        これが真になっていると、サーバーはTCP/IP接続を受け入れます。そうでなければローカルのUnixドメインソケットの接続のみが受け入れられます。デフォルトでは無効です。このオプションはサーバー起動時にのみ設定できます。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>UNIX_SOCKET_DIRECTORY (<type>string</type>)</term> -->
      <term>UNIX_SOCKET_DIRECTORY（<type>文字列</type>）</term>
      <listitem>
       <para>
	<!-- 
        Specifies the directory of the Unix-domain socket on which the
	<application>postmaster</application> is to listen for
	connections from client applications.  The default is normally
	<filename>/tmp</filename>, but can be changed at build time. -->

         <application>postmaster</application>がクライアントアプリケーションからの接続を監視するUnixドメインソケットのディレクトリを指定します。デフォルトは通常<filename>/tmp</filename>ですが、ビルド時に変えることができます。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>UNIX_SOCKET_GROUP (<type>string</type>)</term> -->
      <term>UNIX_SOCKET_GROUP（<type>文字列</type>）</term>
      <listitem>
       <para>
        <!-- 
        Sets the group owner of the Unix domain socket.  (The owning
        user of the socket is always the user that starts the
        postmaster.)  In combination with the option
        <option>UNIX_SOCKET_PERMISSIONS</option> this can be used as
        an additional access control mechanism for this socket type.
        By default this is the empty string, which uses the default
        group for the current user.  This option can only be set at
        server start. -->

        Unixドメインソケットのグループ所有者を設定します（ソケットを所有するユーザーは通常postmasterを起動するユーザーです）。オプション<option>UNIX_SOCKET_PERMISSIONS</option>と一緒に使うと、このタイプのソケットの追加アクセスコントロール機構として使うことができます。デフォルトでは空文字列で、現在のユーザーのデフォルトグループを使います。このオプションはサーバー起動時にのみ設定できます。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>UNIX_SOCKET_PERMISSIONS (<type>integer</type>)</term> -->
      <term>UNIX_SOCKET_PERMISSIONS（<type>整数</type>）</term>
      <listitem>
       <para>
        <!-- 
        Sets the access permissions of the Unix domain socket.  Unix
        domain sockets use the usual Unix file system permission set.
        The option value is expected to be an numeric mode
        specification in the form accepted by the
        <function>chmod</function> and <function>umask</function>
        system calls.  (To use the customary octal format the number
        must start with a <literal>0</literal> (zero).) -->

        Unixドメインソケットのアクセス権限を設定します。Unixドメインソケットは通常のUnixファイルシステム権限の設定を使います。このオプション値は<function>chmod</function>と<function>umask</function>システムコールが受け付ける数値のモード指定になるはずです（通常使われる8進数のフォーマットを使うためには「<literal>0</literal>」――ゼロで始まらなくてはいけません）。

       </para>

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

        デフォルトの権限は、誰でも接続できる<literal>0777</literal>になっています。代わりとしては<literal>0770</literal>（ユーザーとグループのみです。<option>UNIX_SOCKET_GROUP</option>も見てください）や<literal>0700</literal>（ユーザーのみ）を使うこともできます（Unixソケットには、実際には書き込み権限だけが関係あり、読み込みや実行権限を設定、解除する意味はありません）。

       </para>

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

        このアクセスコントロール機構は<xref linkend="client-authentication">で説明されたものからは独立しています。

       </para>

       <para>
        <!-- This option can only be set at server start. -->
        このオプションはサーバー起動時にのみ設定することができます。 

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>VIRTUAL_HOST (<type>string</type>)</term> -->
      <term>VIRTUAL_HOST（<type>文字列</type>）</term>
      <listitem>
       <para>
	<!-- Specifies the TCP/IP hostname or address on which the
	<application>postmaster</application> is to listen for
	connections from client applications.  Defaults to
	listening on all configured addresses (including localhost).
        -->

        <application>postmaster</application>がクライアントアプリケーションからの接続を受け付ける（listenする）TCP/IPホスト名かアドレスを指定します。デフォルトはすべての設定されたアドレス（ローカルホストを含む）になっています。

       </para>
      </listitem>
     </varlistentry>

    </variablelist>
   </sect2>

   <sect2 id="runtime-config-wal">
    <title>WAL</title>
<indexterm><primary>PostgreSQL</primary><secondary sortas="ぱらめーた">パラメータ</secondary><tertiary>WAL</tertiary></indexterm>
   <para>
    <!-- See also <xref linkend="wal-configuration"> for details on WAL
    tuning. -->

    WAL調整の詳細については<xref linkend="wal-configuration">も参照してください。
</para>

    <variablelist>
     <varlistentry>
      <!-- <term>CHECKPOINT_SEGMENTS (<type>integer</type>)</term> -->
      <term>CHECKPOINT_SEGMENTS（<type>整数</type>）</term>
      <listitem>
       <para>
        <!-- Maximum distance between automatic WAL checkpoints, in logfile
	segments (each segment is normally 16 megabytes).
	This option can only be set at server start or in the
	<filename>postgresql.conf</filename> file. -->

        自動WALチェックポイントの間の最大距離をログファイルセグメントの数（それぞれのセグメントは通常16Mバイトです）で指定します。このオプションはサーバー起動時かファイル<filename>postgresql.conf</filename>でのみ設定できます。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>CHECKPOINT_TIMEOUT (<type>integer</type>)</term> -->
      <term>CHECKPOINT_TIMEOUT（<type>整数</type>）</term>
      <listitem>
       <para>
        <!-- Maximum time between automatic WAL checkpoints, in seconds.
	This option can only be set at server start or in the
	<filename>postgresql.conf</filename> file. -->

        自動WALチェックポイント同士の間隔を秒で指定します。このオプションはサーバー起動時かファイル<filename>postgresql.conf</filename>でのみ設定できます。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>WAL_BUFFERS (<type>integer</type>)</term> -->
      <term>WAL_BUFFERS（<type>整数</type>）</term>
      <listitem>
       <para>
        <!-- Number of disk-page buffers in shared memory for WAL log.
	This option can only be set at server start. -->

        WALログ用の共有メモリ内のディスクページバッファの数です。このオプションはサーバー起動時にのみ設定できます。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>WAL_DEBUG (<type>integer</type>)</term> -->
      <term>WAL_DEBUG（<type>整数</type>）</term>
      <listitem>
       <para>
        <!-- If non-zero, turn on WAL-related debugging output on standard
        error. -->
        もし0でなければ、WAL関係のデバッグ表示を標準エラー出力に出します。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>WAL_FILES (<type>integer</type>)</term> -->
      <term>WAL_FILES（<type>整数</type>）</term>
      <listitem>
       <para>
        <!-- 
        Number of log files that are created in advance at checkpoint
        time.  This option can only be set at server start or in the
	<filename>postgresql.conf</filename> file. -->

        チェックポイント時にあらかじめ作られるログファイルの数ですこのオプションはサーバー起動時かファイル<filename>postgresql.conf</filename>でのみ設定できます。

       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <!-- <term>WAL_SYNC_METHOD (<type>string</type>)</term> -->
      <term>WAL_SYNC_METHOD（<type>文字列</type>）</term>
      <listitem>
       <para>
        <!-- Method used for forcing WAL updates out to disk.  Possible
	values are -->

        WAL更新をディスクに書き出す方法を指定します。可能な値は

	<!-- <literal>FSYNC</> (call fsync() at each commit),
	<literal>FDATASYNC</> (call fdatasync() at each commit),
	<literal>OPEN_SYNC</> (write WAL files with open() option O_SYNC), or
	<literal>OPEN_DATASYNC</> (write WAL files with open() option O_DSYNC)
         . -->

<literal>FSYNC</>（それぞれのコミットでfsync()を呼び出す）、<literal>FDATASYNC</>（それぞれのコミットでfdatasync()を呼び出す）、<literal>OPEN_SYNC</>（open()オプションO_SYNCでWALファイルを書き出す）、<literal>OPEN_DATASYNC</>（open()オプションO_DSYNCでWALファイルを書き出す）の4つです。


	<!-- Not all of these choices are available on all platforms.
        This option can only be set at server start or in the
	<filename>postgresql.conf</filename> file. -->

これらのすべての選択がすべてのプラットフォームで使えるわけではありません。このオプションはサーバー起動時かファイル<filename>postgresql.conf</filename>でのみ設定できます。

       </para>
      </listitem>
     </varlistentry>
    </variablelist>
   </sect2>


   <sect2 id="runtime-config-short">
    <!-- <title>Short options</title> -->
    <title>短いオプション</title>
<indexterm><primary>PostgreSQL</primary><secondary sortas="ぱらめーた">パラメータ</secondary><tertiary sortas="みじかいおぷしょん">短いオプション</tertiary></indexterm>
   <para>
    <!-- For convenience there are also single letter option switches
    available for many parameters. They are described in the following
    table. -->

    便宜上、多くのパラメータには1文字のオプションスイッチがあります。下記の表でそれらを説明します。</para>

    <table>
     <!-- <title>Short option key</title> -->
     <title>短いオプションキー</title>
     <tgroup cols="3">
      <colspec colnum="3" align="center">
      <thead>
       <row>
        <!-- <entry>Short option</entry> 
        <entry>Equivalent</entry>
        <entry>Remark</entry> -->

        <entry>オプション</entry>
        <entry>同義</entry>
        <entry>注意</entry>

       </row>
      </thead>
      <tbody>
       <row>
        <entry>-B <replaceable>x</replaceable></entry>
        <entry>shared_buffers = <replaceable>x</replaceable></entry>
        <entry></entry>
       </row>
       <row>
        <entry>-d <replaceable>x</replaceable></entry>
        <entry>debug_level = <replaceable>x</replaceable></entry>
        <entry></entry>
       </row>
       <row>
        <entry>-F</entry>
        <entry>fsync = off</entry>
        <entry></entry>
       </row>
       <row>
        <entry>-h <replaceable>x</replaceable></entry>
        <entry>virtual_host = <replaceable>x</replaceable></entry>
        <entry></entry>
       </row>
       <row>
        <entry>-i</entry>
        <entry>tcpip_socket = on</entry>
        <entry></entry>
       </row>
       <row>
        <entry>-k <replaceable>x</replaceable></entry>
        <entry>unix_socket_directory = <replaceable>x</replaceable></entry>
        <entry></entry>
       </row>
       <row>
        <entry>-l</entry>
        <entry>ssl = on</entry>
        <entry></entry>
       </row>
       <row>
        <entry>-N <replaceable>x</replaceable></entry>
        <entry>max_connections = <replaceable>x</replaceable></entry>
        <entry></entry>
       </row>
       <row>
        <entry>-p <replaceable>x</replaceable></entry>
        <entry>port = <replaceable>x</replaceable></entry>
        <entry></entry>
       </row>

       <row>
        <entry>-fi、-fh、-fm、-fn、-fs、-ft</entry>
        <entry>enable_indexscan=off、enable_hashjoin=off、enable_mergejoin=off、enable_nestloop=off、enable_seqscan=off、enable_tidscan=off</entry>
        <entry>*</entry>
       </row>
       <row>
        <entry>-S <replaceable>x</replaceable></entry>
        <entry>sort_mem = <replaceable>x</replaceable></entry>
        <entry>*</entry>
       </row>
       <row>
        <entry>-s</entry>
        <entry>show_query_stats = on</entry>
        <entry>*</entry>
       </row>
       <row>
        <entry>-tpa、-tpl、-te</entry>
        <entry>show_parser_stats=on、show_planner_stats=on、show_executor_stats=on</entry>
        <entry>*</entry>
       </row>
      </tbody>
     </tgroup>
    </table>
    <!-- For historical reasons, options marked <quote>*</quote> must be
    passed to the individual backend process via the
    <option>-o</option> postmaster option, for example, -->

<para>歴史的な理由で、<quote>*</quote>マークが付いたオプションはpostmasterオプションの<option>-o</option>で個々のバックエンドプロセスに渡されなくてはいけません。たとえば、以下のようなコマンドもしくは上記で説明されたようにクライアント側からの<envar>PGOPTIONS</envar>を使います。</para>


<screen>
&gt; <userinput>postmaster -o '-S 1024 -s'</userinput>
</screen>
    <!-- 
    or via <envar>PGOPTIONS</envar> from the client side, as explained
    above. -->



   </sect2>
 </sect1>


 <sect1 id="kernel-resources">
  <!-- <title>Managing Kernel Resources</title> -->
  <title>カーネルリソースの管理</title>
<indexterm><primary sortas="かーねるりそーすのかんり">カーネルリソースの管理</primary></indexterm>
<indexterm><primary>PostgreSQL</primary><secondary sortas="かーねるりそーすのかんり">カーネルリソースの管理</secondary></indexterm>
  <para>
   <!-- A large <productname>Postgres</> installation can quickly hit
   various operating system resource limits. (On some systems, the
   factory defaults are so low that you don't even need a really
   <quote>large</> installation.) If you have encountered this kind of
   problem then keep reading. -->

   大きな<productname>Postgres</>のインストレーションになると、はオペレーティングシステムのリソースの限界を容易に越えてしまいます（システムによっては出荷時のデフォルトが低すぎるため<quote>大きな</>インストレーションの要望にも応えられません）。このような問題に遭遇したことがある場合はこの先を読んでください。

  </para>

  <sect2 id="sysvipc">
   <!-- <title>Shared Memory and Semaphores</title> -->
   <title>共有メモリとセマフォ</title>
<indexterm><primary>PostgreSQL</primary><secondary sortas="きょうゆうめもりとせまふぉ">共有メモリとセマフォ</secondary></indexterm>
   <para>
    <!-- Shared memory and semaphores are collectively referred to as
    <quote>System V IPC</> (together with message queues, which are
    not relevant for <productname>Postgres</>). Almost all modern
    operating systems provide these features, but not all of them have
    them turned on or sufficiently sized by default, especially
    systems with BSD heritage. (For the QNX and BeOS ports,
    <productname>Postgres</> provides its own replacement
    implementation of these facilities.) -->

    共有メモリとセマフォはひとまとめにして<quote>System V IPC</>と呼ばれます（メッセージキューとも一緒ですが、<productname>Postgres</>では関係ありません）。ほとんどすべての現代のオペレーティングシステムはこれらの機能を提供しますが、特にBSDの痕跡を引きずるシステムのように、すべてがデフォルトで有効にされたり適当なサイズになっているわけではありません（QNXとBeOSポートでは<productname>Postgres</>はこれらの機能の独自の代替実装を提供しています）。

   </para>

   <para>
    <!-- 
    The complete lack of these facilities is usually manifested by an
    <errorname>Illegal system call</> error upon postmaster start. In
    that case there's nothing left to do but to reconfigure your
    kernel  <productname>Postgres</> won't work without them. 
    -->

    これらの機能の完全な欠落は<errorname>Illegal system call</>エラーでpostmaster起動時に表示されます。その場合はカーネルを設定し直すしかありません。<productname>Postgres</>はこれらの機能なしでは動きません。

   </para>

   <para>
    <!-- When <productname>Postgres</> exceeds one of the various hard
    limits of the IPC resources then the postmaster will refuse to
    start up and should leave a marginally instructive error message
    about which problem was encountered and what needs to be done
    about it.  (See also <xref linkend="postmaster-start-failures">.)
    The relevant kernel parameters are named
    consistently across different systems; <xref
    linkend="sysvipc-parameters"> gives an overview. The methods to
    set them, however, vary; suggestions for some platforms are given
    below. Be warned that it is often necessary to reboot your
    machine at least, possibly even recompile the kernel, to change these
    settings. -->

    <productname>Postgres</>がさまざまなIPCリソースのハードリミットを越えるとpostmasterは起動を拒否し、問題に関する限界条件を教え何をすべきかを示すエラーメッセージを残します（<xref linkend="postmaster-start-failures">も参照してください）。関係するカーネルパラメータは別々のシステム上でも統一して名付けられています（<xref linkend="sysvipc-parameters">で概略がわかります）。しかしこれらを得るためのメソッドは異なります。以下に、いくつかのプラットフォームへの提案を挙げます。これらの設定を変えるには、しばしばマシンを再起動することが必要になり、カーネルをコンパイルし直す必要がある場合さえあるので注意してください。
   </para>


   <table id="sysvipc-parameters">
    <!-- <title>System V IPC parameters</> -->
    <title>System V IPCパラメータ</>
<indexterm><primary>PostgreSQL</primary><secondary sortas="System V IPCぱらめーた">System V IPCパラメータ</secondary></indexterm>
    <tgroup cols="3">
     <thead>
      <row>
       <!-- <entry>Name</> -->
       <entry>名前</>
       <!-- <entry>Description</> -->
       <entry>説明</>
       <!-- <entry>Reasonable values</> -->
       <entry>適当な値</>
      </row>
     </thead>

     <tbody>
      <row>
       <entry><varname>SHMMAX</></>
       <!-- <entry>Maximum size of shared memory segment (bytes)</> -->
       <entry>共有メモリセグメントの最大サイズ（バイト）</>
       <!-- <entry>512 kB + 8192 * buffers + extra ... infinity</entry> -->
       <entry>512Kバイト + 8192 × バッファ数 + その他...無限大</entry>
      </row>

      <row>
       <entry><varname>SHMMIN</></>
       <!-- <entry>Minimum size of shared memory segment (bytes)</> -->
       <entry>共有メモリセグメントの最小サイズ（バイト）</entry>
       <!-- <entry>1 (at most about 256 kB)</> -->
       <entry>1（最大で256Kバイト）</>
      </row>

      <row>
       <entry><varname>SHMSEG</></>
       <!-- <entry>Maximum number of shared memory segments per process</>
       -->
       <entry>プロセスごとの共有メモリセグメントの最大数</>
       <!-- <entry>only 1 segment is needed, but the default is much higher</>
       -->
       <entry>必要なのは1セグメントだけですが、デフォルトではもっと多くなっています</entry>
      </row>

       <row>
        <entry><varname>SHMMNI</></>
        <!-- <entry>Maximum number of shared memory segments system-wide</>
         -->
        <entry>システム全体の共有メモリセグメントの最大数</>
        <!-- <entry>like <varname>SHMSEG</> + room for other applications</>
          -->
        <entry><varname>SHMSEG</>と同様 + 他のアプリケーション用の空間</>
       </row>

       <row>
        <entry><varname>SEMMNI</></>
    <!-- <entry>Maximum number of semaphore identifiers (i.e., sets)</> -->
        <entry>セマフォ識別子の最大数（つまりセット）</>
        <entry>&gt;= ceil(max_connections / 16)</>
       </row>

       <row>
        <entry><varname>SEMMNS</></>
    <!-- <entry>Maximum number of semaphores system-wide</> -->
        <entry>システム全体のセマフォの最大数</>
    <!-- <entry>ceil(max_connections / 16) * 17 + room for other applications
      </> -->
         <entry>ceil(max_connections / 16) * 17 + 他のアプリケーション用の空間
      </>
       </row>

       <row>
        <entry><varname>SEMMSL</></>
        <!-- <entry>Maximum number of semaphores per set</> -->
        <entry>セットごとのセマフォの最大数</>
        <entry>&gt;= 17</>
       </row>

       <row>
        <entry><varname>SEMMAP</></>
     <!-- <entry>Number of entries in semaphore map</> -->
         <entry>セマフォマップの中の項目の数</>
     <!--  <entry>see text</> -->
        <entry>テキストを参照</>
       </row>

       <row>
        <entry><varname>SEMVMX</></>
        <!-- <entry>Maximum value of semaphore</> -->
        <entry>セマフォの最大値</>
        <!-- <entry>&gt;= 255  (The default is often 32767, 
           don't change unless asked to.)</> -->
        <entry>&gt;= 255（デフォルトはしばしば32,767ですが、変更するようにいわれない限り変えないでください）</>
       </row>

     </tbody>
    </tgroup>
   </table>


   <para>
    <!-- 
    The most important shared memory parameter is <varname>SHMMAX</>,
    the maximum size, in bytes, that a shared memory segment can have.
    If you get an error message from <function>shmget</> along the
    lines of <errorname>Invalid argument</> then it is possible that
    this limit has been exceeded. The size of the required shared
    memory segments varies both with the number of requested buffers
    (<option>-B</> option) and the number of allowed connections
    (<option>-N</> option), although the former is the dominant item.
    (You can therefore, as a temporary solution, lower these settings
    to get rid of the failures.) As a rough approximation you can
    estimate the required segment size as the number of buffers times
    the block size (8192 kB by default) plus ample overhead (at least
    half a megabyte). Any error message you might get will contain the
    size of the failed allocation request. -->

    一番重要な共有メモリのパラメータは、共有メモリセグメントが持つことのできる最大サイズのバイト数<varname>SHMMAX</>です。もし<function>shmget</>から<errorname>Invalid argument</>エラーメッセージを受けた場合、このリミットを越えている可能性があります。要求される共有メモリセグメントのサイズは要求されるバッファの数（オプション<option>-B</>）と許されている接続の数（<option>-N</>）によりますが、前者が主要です（したがって、一時的な策として、エラーをなくすためにこれらの設定を低くすることもできます）。大雑把な概算としては、必要とされるセグメントサイズをバッファ数×ブロック数（デフォルトでは8192Kバイト）＋十分なオーバーヘッドです。表示されるすべてのエラーメッセージには失敗したメモリ表示サイズが表示されているはずです。

   </para>

   <para>
    <!-- Less likely to cause problems is the minimum size for shared
    memory segments (<varname>SHMMIN</>), which should be at most
    somewhere around 256 kB for <productname>Postgres</> (it is
    usually just 1). The maximum number of segments system-wide
    (<varname>SHMMNI</>) or per-process (<varname>SHMSEG</>) should
    not cause a problem unless your system has them set to zero. Some
    systems also have a limit on the total amount of shared memory in
    the system; see the platform-specific instructions below. -->

    問題が少ないのは共有メモリセグメントの最小サイズ（<varname>SHMMIN</>）で、<productname>Postgres</>では最大でも256Kバイトのはずです（通常では1です）。システム全体のセグメントの最大数（<varname>SHMMNI</>）もしくはプロセスごとのセグメントの最大数（<varname>SHMSEG</>）は使用しているシステムで0に設定されていない限り問題はないはずです。システムによっては共有メモリの合計値にもリミットを設定してあります。下記のプラットフォーム固有の指示を参照してください。

   </para>

   <para>
    <!-- 
    <productname>Postgres</> uses one semaphore per allowed connection
    (<option>-N</> option), in sets of 16.  Each such set will also
    contain a 17th semaphore which contains a <quote>magic
    number</quote>, to avoid collision with semaphore sets used by
    other applications. The maximum number of semaphores in the system
    is set by <varname>SEMMNS</>, which consequently must be at least
    as high as the connection setting plus one extra for each 16
    allowed connections (see the formula in <xref
    linkend="sysvipc-parameters">).  The parameter <varname>SEMMNI</>
    determines the limit on the number of semaphore sets that can
    exist on the system at one time.  Hence this parameter must be at
    least <literal>ceil(max_connections / 16)</>. Lowering the number
    of allowed connections is a temporary workaround for failures,
    which are usually confusingly worded <quote><errorname>No space
    left on device</></>, from the function <function>semget()</>.
    -->

    <productname>Postgres</>は、許可される接続ごとに1つのセマフォを16のセットで使います（<option>-N</>オプション）。それぞれのそのようなセットは17個目のセマフォを持ち、そのセマフォは他のアプリケーションに使われているセマフォセットとの衝突を避けるための<quote>マジックナンバー</quote>を持っています。システム内のセマフォの最多数は<varname>SEMMNS</>によって設定され、その結果としてその数字は少なくとも接続の設定プラスそれぞれの16の接続のための余分はなければいけません（<xref linkend="sysvipc-parameters">の公式を参照してください）。パラメータ<varname>SEMMNI</>はシステム上に同時に存在できるセマフォセットの数の限度を決定します。ですからこのパラメータは少なくとも<literal>ceil(max_connections / 16)</>以上はなくてはいけません。一時的な失敗の逃げ道としては許可される接続の数を下げることができますが、<quote><errorname>No space left on device</></>という紛らわしい言葉が関数<function>semget()</>から表示されます。


   </para>

   <para>
    <!-- 
    In some cases it might also turn out to be necessary to increase
    <varname>SEMMAP</> to be at least on the order of
    <varname>SEMMNS</>. This parameter defines the size of the
    semaphore resource map, in which each contiguous block of available
    semaphores needs an entry. When a semaphore set is freed it is
    either added to an existing entry that is adjacent to the freed
    block or it is registered under a new map entry. If the map is
    full, the freed semaphores get lost (until reboot). Fragmentation
    of the semaphore space could therefore over time lead to less
    available semaphores than there should be. -->

    場合によっては<varname>SEMMAP</>を少なくとも<varname>SEMMNS</>と同じ数だけ増やすことが必要になる場合があるかもしれません。このパラメータはセマフォリソースマップのサイズを定義し、その中では有効なセマフォのそれぞれの隣接したブロックの項目が必要です。セマフォセットが解放されると、解放されたブロックに隣接するすでに存在する項目に追加されるか、もしくは新しいマップの項目の下に登録されます。もしマップが一杯だった場合、解法されたセマフォは（再起動するまで）失われます。したがってセマフォ空間の断片化により時間が経つごとに、有効なセマフォがあるべきよりも少なくなる可能性があります。

   </para>

   <para>
    <!-- 
    The <varname>SEMMSL</> parameter, which determines how many
    semaphores can be in a set, must be at least 17 for
    <productname>Postgres</>. -->

    1つのセットの中にいくつのセマフォがあるかを決める<varname>SEMMSL</>は<productname>Postgres</>では少なくとも17はなくてはいけません。
   </para>

   <para>
    <!-- 
    Various other settings related to <quote>semaphore undo</>, such as
    <varname>SEMMNU</> and <varname>SEMUME</>, are not of concern
    for <productname>Postgres</>. -->

     <varname>SEMMNU</> and <varname>SEMUME</>のような、その他のさまざまな<quote>semaphore undo</>に関する設定は<productname>Postgres</>では問題にする必要がありません。

   </para>


    <variablelist>

     <varlistentry>
      <term>BSD/OS</>
      <listitem>
       <formalpara>
        <!-- <title>Shared Memory</> -->
        <title>共有メモリ</> 
        <para>
         <!-- 
         By default, only 4 MB of shared memory is supported. Keep in
         mind that shared memory is not pageable; it is locked in RAM.
	 The shared memory parameters are: -->

         デフォルトでは、4Mバイトの共有メモリしかサポートされていません。共有メモリはページングできないことを覚えておいてください。RAMの中にロックされているのです。共有メモリのパラメータは以下のとおりです。</para>

       </formalpara>

<para>
<programlisting>
<!-- #define SHMMAX    /* max shared memory segment size (bytes) */
#define SHMMIN    /* min shared memory segment size (bytes) */
#define SHMMNI    /* max number of shared memory identifiers */
#define SHMSEG    /* max shared memory segments per process */
#define SHMALL    /* max amount of shared memory (pages) */ -->
#define SHMMAX    /* 共有メモリの最大セグメントサイズ（バイト）*/
#define SHMMIN    /* 共有メモリの最小セグメントサイズ（バイト）*/
#define SHMMNI    /* 共有メモリ識別子の最大数 */
#define SHMSEG    /* プロセスごとの共有メモリセグメントの最大数 */
#define SHMALL    /* 共有メモリの最大値（ページ）*/
</programlisting>
</para>

<!-- 
 To increase the number of buffers supported by the postmaster, add the
 following to your kernel config file.  A <varname>SHMALL</> value of 1024 
 represents 4MB of shared memory.  Increase it accordingly:
-->

<para>postmasterがサポートするバッファの数を増やすためには、下記をカーネル設定ファイルに追加してください。4096を指定した<varname>SHMALL</>値は共有メモリの4Mバイトを表します。必要に応じて増やしてください。</para>

<para>
<programlisting>
options "SHMALL=4096"
options "SHMMAX=&bsol;(SHMALL*PAGE_SIZE&bsol;)"
</programlisting>
</para>

       <para>
        <!--
        For those running 4.1 or later, just recompile the kernel and
        reboot. For those running earlier releases, use
        <application>bpatch</> to find the <varname>sysptsize</> value
        for the current kernel. This is computed dynamically at
        bootup. -->

        4.1以降のものを使っている場合は、ただカーネルをコンパイルし直して再起動してください。それ以前のものを使っている方は、現在のカーネルの<varname>sysptsize</>値を見つけるため<application>bpatch</>を使ってください。これは起動時に動的に計算されます。</para>

<screen>
$ <userinput>bpatch -r sysptsize</>
<computeroutput>0x9 = 9</>
</screen>
        <!-- 
        Next, change <varname>SYSPTSIZE</> to a hard-coded value. Use
        the bpatch value, plus add 1 for every additional 4 MB of
        shared memory you desire. -->

<para>次に、<varname>SYSPTSIZE</>をハードコーディングされた値に変えてください。bpatch値を使い、さらに希望する共有メモリの4Mバイトごとに1を追加してください。</para>

<programlisting>
options "SYSPTSIZE=13"
</programlisting>
        <!--
        <varname>sysptsize</> can not be changed by sysctl on the fly. -->

<para><varname>sysptsize</>は、起動中にsysctlによって動的に変えることはできません。

       </para>

       <formalpara>
        <!-- <title>Semaphores</> -->
        <title>セマフォ</>
        <para>
         <!-- You may need to increase the number of semaphores. By
         default, <productname>Postgres</> allocates 34 semaphores,
	 which is over half the default system total of 60. -->

         セマフォの数を増やす必要がある場合があるかもしれません。デフォルトでは<productname>Postgres</>は34のセマフォを割り当てていますが、これはシステム合計のデフォルトである60の半分以上です。
        </para>
       </formalpara>

       <para>
        <!-- The defaults are in <filename>/sys/sys/sem.h</>: -->
        デフォルトは<filename>/sys/sys/sem.h</>です。</para>

<programlisting>
<!--#define SEMMNI  10              /* # of semaphore identifiers */

#define SEMMNS  60              /* # of semaphores in system */

#define SEMUME  10              /* max # of undo entries per process */

#define SEMMNU  30              /* # of undo structures in system */ -->
#define SEMMNI  10              /* セマフォ識別子の数 */

#define SEMMNS  60              /* システム内のセマフォの数 */

#define SEMUME  10              /* プロセスごとの取り消し項目の最高数 */

#define SEMMNU  30              /* システム内の取り消し構造体の数 */
</programlisting>
   <!-- Set the values you want in your kernel config file, e.g.: -->
<para>設定ファイルの中に必要な値を設定してください。たとえば下記のようになります。</para>

<programlisting>
options "SEMMNI=40"
options "SEMMNS=240"
options "SEMUME=40"
options "SEMMNU=120"
</programlisting>
      </listitem>
     </varlistentry>


     <varlistentry>
      <term>FreeBSD</term>
      <term>OpenBSD</term>
      <listitem>
       <para>
      <!--  The options <varname>SYSVSHM</> and <varname>SYSVSEM</> need
        to be enabled when the kernel is compiled. (They are by
        default.) The maximum size of shared memory is determined by
        the option <varname>SHMMAXPGS</> (in pages). The following
        shows an example of how to set the various parameters:
      -->

      オプション<varname>SYSVSHM</>と<varname>SYSVSEM</>はカーネルのコンパイル時に動作可能にする必要があります（デフォルトでは動作可能になっています）。共有メモリの最大サイズはオプション<varname>SHMMAXPGS</>（ページ数）で決定されます。以下に、さまざまなパラメータの設定方法の例を示します。</para>

<programlisting>
options         SYSVSHM
options         SHMMAXPGS=4096
options         SHMSEG=256

options         SYSVSEM
options         SEMMNI=256
options         SEMMNS=512
options         SEMMNU=256
options         SEMMAP=256
</programlisting>
      </listitem>
     </varlistentry>


     <varlistentry>
      <term>HP-UX</>
      <listitem>
       <para>
        <!-- 
        The default settings tend to suffice for normal installations.
        On <productname>HP-UX</> 10, the factory default for
        <varname>SEMMNS</> is 128, which might be too low for larger
        database sites. -->

        デフォルトの設定は通常のインストールではほぼ十分です。<productname>HP-UX</> 10では<varname>SEMMNS</>の製造デフォルトは128ですが、これは大きなデータベースサイトには低すぎるかもしれません。

       </para>
       <para>
        <!-- IPC parameters can be set in the <application>System
        Administration Manager</> (<acronym>SAM</>) under
        <menuchoice><guimenu>Kernel
        Configuration</><guimenuitem>Configurable Parameters</></>.
        Hit <guibutton>Create A New Kernel</> when you're done.
        -->

        IPCパラメータは<menuchoice><guimenu>Kernel Configuration</><guimenuitem>Configurable Parameters</></>の下で、<application>システム管理マネージャ</>（<acronym>SAM</>）の中で設定することができます。終わったら<guibutton>Create A New Kernel</>を押してください。

       </para>
      </listitem>
     </varlistentry>


     <varlistentry>
      <term>Linux</>
      <listitem>
       <para>
        <!-- The default shared memory limit (both
        <varname>SHMMAX</varname> and <varname>SHMALL</varname>) is 32
        MB in 2.2 kernels, but it can be changed in the
        <filename>proc</filename> file system (without reboot).  For
        example, to allow 128 MB: -->

        共有メモリ制限のデフォルト（<varname>SHMMAX</varname>と<varname>SHMALL</varname>の両方とも）は2.2カーネルで32Mバイトですが、<filename>proc</filename>ファイルシステムで変えることができます（再起動なし）。たとえば128Mバイトを許可するためには下記のようになります。 </para>

<screen>
<prompt>$</prompt> <userinput>echo 134217728 >/proc/sys/kernel/shmall</userinput>
<prompt>$</prompt> <userinput>echo 134217728 >/proc/sys/kernel/shmmax</userinput>
</screen>
       <!--  
       You could put these commands into a script run at boot-time. 
        -->
<para>これらのコマンドは起動時に実行されるスクリプトに書いておくことができます。
       </para>

       <para>
        <!-- Alternatively, you can use
        <citerefentry><refentrytitle>sysctl</refentrytitle>
        <manvolnum>8</manvolnum></citerefentry>, if available, to
        control these parameters.  Look for a file called
        <filename>/etc/sysctl.conf</filename> and add lines like the
        following to it:
        -->

        これらのパラメータをコントロールするために、もし有効であれば<citerefentry><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>を代わりに使うこともできます。<filename>/etc/sysctl.conf</filename>というファイルを探し、以下の2行をそれに追加してください。</para>

<programlisting>
kernel.shmall = 134217728
kernel.shmmax = 134217728
</programlisting>
        <!-- This file is usually processed at boot time, but
        <application>sysctl</application> can also be called
        explicitly later.
        -->

<para>このファイルは通常は起動時に処理されますが、<application>sysctl</application>は後で明示的に呼び出すこともできます。
       </para>

       <para>
        <!--  
        Other parameters are sufficiently sized for any application.
        If you want to see for yourself look into
        <filename>/usr/src/linux/include/asm-<replaceable>xxx</>/shmparam.h</>
        and <filename>/usr/src/linux/include/linux/sem.h</>.
        -->

        他のパラメータはどんなアプリケーションにも合うようなサイズに設定されています。自分で確認したい場合は、<filename>/usr/src/linux/include/asm-<replaceable>xxx</>/shmparam.h</>と<filename>/usr/src/linux/include/linux/sem.h</>を参照してください。

       </para>
      </listitem>
     </varlistentry>


     <varlistentry>
      <term>SCO OpenServer</>
      <listitem>
       <para>
        <!-- 
        In the default configuration, only 512 kB of shared memory per
        segment is allowed, which is about enough for <option>-B 24 -N
        12</>. To increase the setting, first change the directory to
        <filename>/etc/conf/cf.d</>. To display the current value of
        <varname>SHMMAX</>, in bytes, run
        -->

        デフォルトの設定では、セグメントごとに512Kバイトの共有メモリしか許可されていませんが、これは<option>-B 24 -N 12</>にはほぼ十分です。設定を増やすためには、まず<filename>/etc/conf/cf.d</>ディレクトリに移動してください。現在の<varname>SHMMAX</>値をバイトで表示するためには下記を実行してください。</para>

<programlisting>
./configure -y SHMMAX
</programlisting>
        <!-- To set a new value for <varname>SHMMAX</>, run:
        -->

<para><varname>SHMMAX</>の新しい値を設定するためには、<replaceable>value</>が使おうとしている新しい値（バイトで）で下記を実行してください。</para>

<programlisting>
./configure SHMMAX=<replaceable>value</>
</programlisting>
        <!-- 
        where <replaceable>value</> is the new value you want to use
        (in bytes). After setting <varname>SHMMAX</>, rebuild the kernel
        -->

<para><varname>SHMMAX</>の設定が終わったら、カーネルをビルドし直してください。</para>

<programlisting>
./link_unix
</programlisting>
        <!-- and reboot. -->
<para>そして再起動してください。</para>
      </listitem>
     </varlistentry>


     <varlistentry>
      <term>Solaris</>
      <listitem>
       <para>
        <!-- At least in version 2.6, the maximum size of a shared memory
        segment is set too low for <productname>Postgres</>. The
        relevant settings can be changed in <filename>/etc/system</>,
        for example:
        -->

        少なくともバージョン2.6では共有メモリセグメントの最大サイズは<productname>Postgres</>には低すぎる設定になっています。必要な設定は<filename>/etc/system</>で変えることができ、たとえば以下のようになります。</para>

<programlisting>
set shmsys:shminfo_shmmax=0x2000000
set shmsys:shminfo_shmmin=1
set shmsys:shminfo_shmmni=256
set shmsys:shminfo_shmseg=256

set semsys:seminfo_semmap=256
set semsys:seminfo_semmni=512
set semsys:seminfo_semmns=512
set semsys:seminfo_semmsl=32
</programlisting>
        <!-- You need to reboot to make the changes effective. -->
<para>変化を反映させるには再起動する必要があります。
       </para>

       <para>
        <!-- See also <ulink
        url="http://www.sunworld.com/swol-09-1997/swol-09-insidesolaris.html">http://www.sunworld.com/swol-09-1997/swol-09-insidesolaris.html</>
        for information on shared memory under
        <productname>Solaris</>.
        -->

        <productname>Solaris</>の下の共有メモリに関する情報については、<ulink url="http://www.sunworld.com/swol-09-1997/swol-09-insidesolaris.html">http://www.sunworld.com/swol-09-1997/swol-09-insidesolaris.html</>も参照してください。
       </para>
      </listitem>
     </varlistentry>


     <varlistentry>
      <term>UnixWare</>
      <listitem>
       <para>
        <!-- On <productname>UnixWare</> 7, the maximum size for shared
        memory segments is 512 kB in the default configuration. This
        is enough for about <option>-B 24 -N 12</>. To display the
        current value of <varname>SHMMAX</>, run
        -->

        <productname>UnixWare</> 7では、共有メモリセグメントの最大サイズはデフォルト設定で512Kバイトです。これは<option>-B 24 -N 12</>にはおよそ十分です。現在の<varname>SHMMAX</>値を表示するためには下記を実行してください。</para>

<programlisting>
/etc/conf/bin/idtune -g SHMMAX
</programlisting>
        <!-- which displays the current, default, minimum, and maximum
        values, in bytes. To set a new value for <varname>SHMMAX</>,
        run:
        -->

<para>これは現在の、デフォルトの、最小の、そして最大の、値をバイトで表示します。<varname>SHMMAX</>の新しい値を設定するためには下記を、<replaceable>value</>が使おうとしている新しい値で（バイトで）実行してください。</para>

<programlisting>
/etc/conf/bin/idtune SHMMAX <replaceable>value</>
</programlisting>
        <!-- where <replaceable>value</> is the new value you want to use
        (in bytes). After setting <varname>SHMMAX</>, rebuild the
        kernel
        -->

<para><varname>SHMMAX</>の設定が終わったらカーネルのビルドをし直します。</para>

<programlisting>
/etc/conf/bin/idbuild -B
</programlisting>
        <!-- and reboot. -->
<para>その後再起動してください。
       </para>
      </listitem>
     </varlistentry>

    </variablelist>

  </sect2>


  <sect2>
   <!-- <title>Resource Limits</title> -->
   <title>リソースの制限</title>
<indexterm><primary>PostgreSQL</primary><secondary sortas="りそーすのせいげん">リソースの制限</secondary></indexterm>
   <para>
    <!-- Unix-like operating systems enforce various kinds of resource
    limits that might interfere with the operation of your
    <productname>Postgres</productname> server.  Of importance are
    especially the limits on the number of processes per user, the
    number of open files per process, and the amount of memory
    available to a process.  Each of these have a <quote>hard</quote>
    and a <quote>soft</quote> limit.  The soft limit is what actually
    counts but it can be changed by the user up to the hard limit.
    The hard limit can only be changed by the root user.  The system
    call <function>setrlimit</function> is responsible for setting
    these parameters.  The shell's built-in command
    <command>ulimit</command> (Bourne shells) or
    <command>limit</command> (csh) is used to control the resource
    limits from the command line.  On BSD-derived systems the file
    <filename>/etc/login.conf</filename> controls what values the
    various resource limits are set to upon login.  See
    <citerefentry><refentrytitle>login.conf</refentrytitle>
    <manvolnum>5</manvolnum></citerefentry> for details.  The relevant
    parameters are <varname>maxproc</varname>,
    <varname>openfiles</varname>, and <varname>datasize</varname>.
    For example:
    -->

    Unixライクなオペレーティングシステムでは<productname>Postgres</productname>サーバーの操作と関係する可能性のあるさまざまな種類のリソース制限があります。重要なのは、特にユーザーごとのプロセス数の制限、プロセスごとのオープンファイルの数、1つのプロセスに対して有効なメモリの量です。これらのそれぞれが<quote>ハード</quote>と<quote>ソフト</quote>の2つの制限を持っています。ソフト制限が実際に有効な制限ですが、ユーザーによってハード制限まで変えることが可能です。ハード制限はルートユーザーによってのみ変えることができます。システムコール<function>setrlimit</function>がこれらのパラメータの設定を行います。シェルに組み込まれたコマンド<command>ulimit</command>（Bourne shells）もしくは<command>limit</command>（csh）は、コマンドラインからリソース制限をコントロールするために使われます。BSD派生システム上ではファイル<filename>/etc/login.conf</filename>が、さまざまなリソース制限がログイン時にどの値に設定されるかをコントロールします。詳細は<citerefentry><refentrytitle>login.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>を参照してください。関連するパラメータは<varname>maxproc</varname>、<varname>openfiles</varname>、<varname>datasize</varname>です。たとえば下記のようになります（<literal>-cur</literal>がソフト制限です。ハード制限を設定するためには<literal>-max</literal>を付けてください）。</para>

<programlisting>
default:&bsol;
...
        :datasize-cur=256M:&bsol;
        :maxproc-cur=256:&bsol;
        :openfiles-cur=256:&bsol;
...
</programlisting>
    <!-- (<literal>-cur</literal> is the soft limit.  Append
    <literal>-max</literal> to set the hard limit.) 
    -->

   <para>
    <!--Kernels generally also have an implementation-dependent
    system-wide limit on some resources.
    -->
    カーネルは一般的にはいくつかのリソースに対して、実装に依存するシステム全体の制限も持っています。
</para>

    <itemizedlist>
     <listitem>
      <para>
      <!-- On <productname>Linux</productname>
      <filename>/proc/sys/fs/file-max</filename> determines the
      maximum number of files that the kernel will allocate.  It can
      be changed by writing a different number into the file or by
      adding an assignment in <filename>/etc/sysctl.conf</filename>.
      The maximum limit of files per process is fixed at the time the
      kernel is compiled; see
      <filename>/usr/src/linux/Documentation/proc.txt</filename> for
      more information.
      -->

      <productname>Linux</productname>では、<filename>/proc/sys/fs/file-max</filename>が、カーネルが割り当てるファイル数の最大を決定します。この数を変えるためには、そのファイルにに別の数を書き込むか、あるいは<filename>/etc/sysctl.conf</filename>に代入値を追加します。プロセスごとのファイルの最大制限はカーネルがコンパイルされたときに固定されます。詳しい情報は<filename>/usr/src/linux/Documentation/proc.txt</filename>を参照してください。

      </para>
     </listitem>
    </itemizedlist>

   <para>
    <!-- 
    The <productname>Postgres</productname> server uses one process
    per connection so you should provide for at least as many processes
    as allowed connections, in addition to what you need for the rest
    of your system.  This is usually not a problem but if you run
    several servers on one machine things might get tight.
    -->

    <productname>Postgres</productname>サーバーはコネクションごとに1つのプロセスを使うので、少なくとも許可された接続の数だけのプロセスに残りのシステムで必要な分を追加したものが必要になります。通常はこれは問題ではありませんが、1つのマシン上でいくつかのサーバーを起動している場合は厳しい状況になるかもしれません。

   </para>

   <para>
    <!-- The factory default limit on open files is often set to
    <quote>socially friendly</quote> values that allow many users to
    coexist on a machine without using an inappropriate fraction of
    the system resources.  If you run many servers on a machine this
    is perhaps what you want, but on dedicated servers you may want to
    raise this limit.
    -->

    オープンファイルの制限の出荷時のデフォルトは、しばしば大多数のユーザーはマシン上でシステムリソースの不正使用をしないという前堤に立った<quote>社会的に友好的な</quote>値を設定してしまいます。もし1つのマシン上で複数のサーバーを起動する場合はそれが必要でしょうが、専用サーバーではこの制限を上げたいかもしれません。

   </para>
  </sect2>

 </sect1>


 <sect1 id="postmaster-shutdown">
  <!-- <title>Shutting down the server</title> -->
  <title>サーバーのシャットダウン</title>
<indexterm><primary sortas="さーばーのしゅうりょう">サーバーの終了</primary></indexterm>
<indexterm><primary>PostgreSQL</primary><secondary sortas="さーばーのしゅうりょう">サーバーの終了</secondary></indexterm>
  <para>
   <!-- 
   Depending on your needs, there are several ways to shut down the
   database server when your work is done. The differentiation is
   done by what signal you send to the server process.
   -->

   必要に応じて、仕事が終わったときにデータベースサーバーをシャットダウンする方法がいくつかあります。サーバープロセスに送るシグナルによって方法が区別されます。</para>


   <variablelist>
    <varlistentry>
     <term>SIGTERM</term>
     <listitem>
      <para>
       <!-- After receiving SIGTERM, the postmaster disallows new
       connections, but lets existing backends end their work normally.
       It shuts down only after all of the backends terminate by client
       request.
       This is the <firstterm>Smart Shutdown</firstterm>.
       -->

       SIGTERMを受け取った後で、postmasterは新しい接続を禁止しますが、すでに存在するバックエンドは通常どおり動作させます。クライアントの要求によってすべてのバックエンドが終了するまではシャットダウンしません。これが<firstterm>スマートシャットダウン</firstterm>です。<indexterm><primary sortas="すまーとしゃっとだうん">スマートシャットダウン</primary></indexterm><indexterm><primary>postmaster</primary><secondary sortas="すまーとしゃとだうん">スマートシャットダウン</secondary></indexterm>

      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term>SIGINT</term>
     <listitem>
      <para>
       <!-- 
       The postmaster disallows new connections and sends all existing
       backends SIGTERM, which will cause them to abort their current
       transactions and exit promptly.  It then waits for the backends to exit
       and finally shuts down the data base.
       This is the <firstterm>Fast Shutdown</firstterm>.
       -->

       postmasterは新しい接続を禁止しすべての存在するバックエンドにSIGTERMを送り、この結果バックエンドは現在のトランザクションをアボートし、即座に終了します。そしてpostmasterはバックエンドの終了を待って、最後にデータベースをシャットダウンします。これは<firstterm>速いシャットダウン</firstterm>です。<indexterm><primary sortas="はやいしゃっとだうん">速いシャットダウン</primary></indexterm><indexterm><primary>postmaster</primary><secondary sortas="はやいしゃっとだうん">速いシャットダウン</secondary></indexterm>
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term>SIGQUIT</term>
     <listitem>
      <para>
       <!-- 
       This is the <firstterm>Immediate Shutdown</firstterm> which
       will cause the postmaster to send a SIGQUIT to all backends and
       exit immediately (without properly shutting down the database
       system).  The backends likewise exit immediately upon receiving
       SIGQUIT. This will lead to recovery (by replaying the WAL log)
       upon next start-up.  This is recommended only in emergencies.
       -->

       これは<firstterm>即時シャットダウン</firstterm>と呼ばれ、postmasterにすべてのバックエンドにSIGQUITを送らせ即座に終了（データベースを正しく終了させずに）させます。バックエンドは同様にSIGQUITを受け取ると同時に終了します。これは次の起動時に（WALログを再実行することで）リカバリをすることになります。これは緊急のときにのみ使うことを勧めます。<indexterm><primary sortas="そくじしゃっとだうん">即時シャットダウン</primary></indexterm><indexterm><primary>postmaster</primary><secondary sortas="そくじしゃっとだうん">即時シャットダウン</secondary></indexterm>

      </para>
     </listitem>
    </varlistentry>
   </variablelist>

   <caution>
    <para>
     <!--  
     It is best not to use SIGKILL to shut down the postmaster. This
     will prevent the postmaster from releasing shared memory and
     semaphores, which you may then have to do by hand.
     -->
     postmasterをシャットダウンするためにはSIGKILLを使わない方がよいでしょう。それによってpostmasterが共有メモリとセマフォをリリースできなくなり、手動でその作業をしなければならなくなる可能性があります。

    </para>
   </caution>

   <!-- The PID of the postmaster process can be found using the
   <application>ps</application> program, or from the file
   <filename>postmaster.pid</filename> in the data directory. So for
   example, to do a fast shutdown:
   -->

<para>
postmasterプロセスのPIDは<application>ps</application>プログラムを使って見つけるか、もしくはデータディレクトリの中のファイル<filename>postmaster.pid</filename>から見つけることができます。ですから、たとえば速いシャットダウンをするためには下記のようになります。<indexterm><primary>postmaster.pid</primary></indexterm><indexterm><primary>PostgreSQL</primary><secondary>postmaster.pid</secondary></indexterm>
</para>


<screen>
&gt; <userinput>kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`</userinput>
</screen>

  <para>
   <!-- The program <application>pg_ctl</application> is a shell script
   that provides a more convenient interface for shutting down the
   postmaster.
   -->

   プログラム<application>pg_ctl</application>はpostmasterのシャットダウンのもっと便利なインターフェイスを提供するシェルスクリプトです。

  </para>
 </sect1>

 <sect1 id="ssl-tcp">
  <!-- <title>Secure TCP/IP Connections with SSL</title>-->
  <title>SSLによる安全なTCP/IP接続</title>
<indexterm><primary>SSL</primary></indexterm>
<indexterm><primary>PostgreSQL</primary><secondary>SSL</secondary></indexterm>
  <para>
   <!-- 
   <productname>PostgreSQL</> has native support for connections over
   <acronym>SSL</> to encrypt
   client/server communications for increased security. This requires
   <productname>OpenSSL</productname> to be installed on both client
   and server systems and support enabled at build-time (see <xref
   linkend="installation">).
   -->

   <productname>PostgreSQL</>は本来的に<acronym>SSL</>越しの接続をサポートし、クライアント/サーバーの通信がさらに安全になるよう暗号化します。そのためには<productname>OpenSSL</productname>がクライアントとサーバーシステムの両方にインストールされビルド時に動作可能になっている必要があります（<xref linkend="installation">を参照してください）。<indexterm><primary>OpenSSL</primary></indexterm>
 
  </para>

  <para>
   <!-- 
   With SSL support compiled in, the <productname>PostgreSQL</> server
   can be started with the argument <option>-l</> (ell) to enable
   SSL connections. When starting in SSL mode, the postmaster will look
   for the files <filename>server.key</> and <filename>server.crt</> in
   the data directory.  These files should contain the server private key
   and certificate respectively. These files must be set up correctly
   before an SSL-enabled server can start. If the private key is protected
   with a passphrase, the postmaster will prompt for the passphrase and will
   not start until it has been entered.
   -->

   SSLサポートでコンパイルされると、<productname>PostgreSQL</>サーバーはSSL接続を動作可能にするために引数<option>-l</>（アルファベットのエル）と一緒に起動することができるようになります。SSLモードで起動するときは、postmasterはファイル<filename>server.key</>と<filename>server.crt</>をデータディレクトリの中から探します。これらのファイルはSSLが動作可能なサーバーが起動する前に正しく設定されなけばいけません。もしプライベートキーがパスフレーズで保護されている場合は、postmasterはパスフレーズの入力を促し、入力されるまでは起動しません。

  </para>

  <para>
   <!-- 
   The postmaster will listen for both standard and SSL connections
   on the same TCP/IP port, and will negotiate with any connecting
   client whether or not to use SSL.
   See <xref linkend="client-authentication">
   about how to force on the server side the use of SSL for certain
   connections. -->

   postmasterは標準接続とSSL接続接続の両方を同じTCP/IPポート上で待ち受け（listen）し、接続してきたクライアントとSSLを使用するかどうかを交渉します。特定の接続に対し、サーバー側でSSLの使用を強要する方法については<xref linkend="client-authentication">を参照してください。

  </para>

  <para>
   <!-- 
   For details on how to create your server private key and certificate,
   refer to the <productname>OpenSSL</> documentation. A simple self-signed
   certificate can be used to get started for testing, but a certificate signed
   by a CA (either one of the global CAs or a local one) should be used in 
   production so the client can verify the servers identity. To create
   a quick self-signed certificate, use the following OpenSSL command:
   -->

   サーバーのプライベートキーと証明書を作成する方法の詳細は<productname>OpenSSL</>のドキュメントを参照してください。テストで使い始めるにあたり簡単な自筆署名の証明書を使うことができますが、製品として使うにはCA（世界共通の認証局もしくは地元認証局）の署名付き証明書を使うべきで、そうすることによりクライアントはサーバー身元を確認できます。自筆署名の証明書を作るためには下記のOpenSSLコマンドを使ってください。</para>

<programlisting>
openssl req -new -text -out cert.req
</programlisting>
   <!-- 
   Fill out the information that openssl asks for. Make sure that you enter
   the local host name as Common Name; the challenge password can be
   left blank. The script will generate a key that is passphrase protected;
   it will not accept a pass phrase that is less than four characters long.
   To remove the passphrase (as you must if you want automatic start-up of
   the postmaster), run the commands
   -->

<para>opensslから出される質問に答えてください。このとき、Common Nameにはローカルホスト名を入力して、チャレンジパスワードは空白でも構いません。スクリプトがパスフレーズで保護されたキーを生成しますが、4文字以下のパスフレーズは認められません。パスフレーズを削除するためには（postmasterの自動起動を行いたいのであれば）、下記のコマンドを実行してください。</para>

<programlisting>
openssl rsa -in privkey.pem -out cert.pem
</programlisting>
   <!-- Enter the old passphrase to unlock the existing key. Now do
   -->
<para>すでに存在するキーのロックを外すために、古いパスフレーズを入力します。そして、下記を実行してください。</para>

<programlisting>
openssl req -x509 -in cert.req -text -key cert.pem -out cert.cert
cp cert.pem <replaceable>$PGDATA</replaceable>/server.key
cp cert.cert <replaceable>$PGDATA</replaceable>/server.crt
</programlisting>
   <!-- to turn the certificate into a self-signed certificate and to copy the
   key and certificate to where the postmaster will look for them.
   -->

<para>このように、証明書を自筆署名の証明書にして、キーと証明書とをpostmasterが見つけられる場所にコピーします。
  </para>
 </sect1>

 <sect1 id="ssh-tunnels">
  <!-- <title>Secure TCP/IP Connections with SSH tunnels</title> -->
  <title>SSHトンネルを使った安全なTCP/IP接続</title>
<indexterm><primary>SSH</primary></indexterm>
<indexterm><primary>PostgreSQL</primary><secondary>SSH</secondary></indexterm>
  <note>
   <!-- <title>Acknowledgement</title> -->
   <title>謝辞</title>
   <para>
    <!-- Idea taken from an email by Gene Selkov, Jr.
    (<email>selkovjr@mcs.anl.gov</>) written on 1999-09-08 in response
    to a question from Eric Marsden. -->

    Gene Selkov,Jr.（<email>selkovjr@mcs.anl.gov</>）からEric Marsdenの質問に対する返事として1999-09-08に書かれた電子メールからアイディアをもらいました。
   </para>
  </note>

  <para>
   <!-- 
   One can use <productname>ssh</productname> to encrypt the network
   connection between clients and a
   <productname>Postgres</productname> server. Done properly, this
   should lead to an adequately secure network connection.
   -->

   <productname>ssh</productname>をクライアントと<productname>Postgres</productname>サーバー間のネットワークを暗号化するために使うことができます。正しく行えば、これで十分に安全なネットワーク接続を行うことができるようになるばずです。

  </para>

  <para>
   <!--
   First make sure that an <productname>ssh</productname> server is
   running properly on the same machine as
   <productname>Postgres</productname> and that you can log in using
   ssh as some user. Then you can establish a secure tunnel with a
   command like this from the client machine:
   -->

   まず<productname>ssh</productname>サーバーが<productname>Postgres</productname>と同じマシン上で正しく起動していて、sshを使ってログインできるユーザーが存在することを確かめてください。そうすると、次に示すコマンドでクライアントマシンから安全なトンネルを確立することができます。</para>

<programlisting>
&gt; <userinput>ssh -L 3333:foo.com:5432 joe@foo.com</userinput>
</programlisting>
   <!-- 
   The first number in the <option>-L</option> argument, 3333, is the
   port number of your end of the tunnel; it can be chosen freely. The
   second number, 5432, is the remote end of the tunnel __ the port
   number your backend is using. The name or the address in between
   the port numbers is the host with the database server you are going
   to connect to. In order to connect to the database server using
   this tunnel, you connect to port 3333 on the local machine:
   -->

<para><option>-L</option>引数の1番目の数字（3333）はトンネルのローカル側のポート番号で、自由に選択することが可能です。2番目の数字（5432）は、トンネルのリモート側のバックエンドが使用しているポート番号です。2つのポート番号間の名前もしくはアドレスは、接続しようとしているデータベースサーバーのホストです。このトンネルを使ってデータベースサーバーに接続するためには、ローカルマシンのポート3333に接続します。</para>

<programlisting>
psql -h localhost -p 3333 template1
</programlisting>
   <!-- 
   To the database server it will then look as though you are really
   user <literal>joe@foo.com</literal> and it will use whatever
   authentication procedure was set up for this user. In order for the
   tunnel setup to succeed you must be allowed to connect via ssh as
   joe@foo.com, just as if you had attempted to use ssh to set up a
   terminal session. -->

<para>データベースサーバーにとっては、ユーザーが実際に<literal>joe@foo.com</literal>であるかのように見え、認証プロシージャがこのユーザー（joe@foo.com）のために発行した証明書を使います。トンネルの確立が成功するためには、sshを使用して端末セッションを確立したのと同様に、ユーザーjoe@foo.comがsshを通して接続することが許可されていなければいけません。

  </para>

  <tip>
   <para>
    <!-- 
    Several other products exist that can provide secure tunnels using
    a procedure similar in concept to the one just described.
    -->
    ここで説明してきた概念に似た手続きを使用する、安全なトンネルを用意できる製品がほかにもいくつか存在します。

   </para>
  </tip>

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