<!-- doc/src/sgml/restrictions.sgml -->

<sect1 id="restrictions">
<!--
 <title>Restrictions</title>
-->
 <title>制限事項</title>

 <para>
<!--
  This section descibes current restrictions of <productname>Pgpool-II</productname>.
-->
この章では、<productname>Pgpool-II</productname>の現在の制限事項について説明します。

  <variablelist>

   <varlistentry>
<!--
    <term>Functionality of PostgreSQL</term>
-->
    <term>PostgreSQLの機能</term>
    <listitem>
     <para>
<!--
       If you use <function>pg_terminate_backend()</function> to stop
       a backend, this will trigger a failover.  The reason why this
       happens is that <productname>PostgreSQL</productname> sends
       exactly the same message for a terminated backend as for a full
       postmaster shutdown.  There is no workaround prior of version
       3.6. From version 3.6, this limitation has been mitigated. If
       the argument to the function (that is a process id) is a
       constant, you can safely use the function. In extended protocol
       mode, you cannot use the function though.
-->
<function>pg_terminate_backend()</function>を使ってバックエンドを停止すると、フェイルオーバが起こります。
これは、<productname>PostgreSQL</productname>が、postmasterの停止と全く同じメッセージをバックエンド停止時に送るためです。
3.6より前のバージョンには回避策はありません。
3.6以降では、この制限は緩和されています。
その関数の引数（プロセスIDです）が定数なら、その関数を使っても安全です。
しかし、拡張プロトコルでは、その関数は使えません。
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
<!--
    <term>Authentication/Access Controls</term>
-->
    <term>認証/アクセス制御</term>
    <listitem>
      <para>
<!--
	In the replication mode or master/slave mode, trust, clear
        text password, and pam methods are supported. md5 in also
        supported since <productname>Pgpool-II</productname> 3.0.  md5
        is supported by using a authencitaion file <filename>pool_passwd</filename>.
        <filename>pool_passwd</filename> is default name of the
        authentication file. Here are the
        steps to enable md5 authentication:
-->
レプリケーションモードまたマスタ/スレーブモード時にはtrust、reject、clear text password、pam認証方式が利用できます。
crypt認証は利用できません。
<productname>Pgpool-II</productname> 3.0以降では、<filename>pool_passwd</filename>というファイルを使ってmd5認証も使えます。
<filename>pool_passwd</filename>はデフォルトの認証ファイル名です。
md5認証を有効にする手順を示します。
      </para>

      <orderedlist>

	<listitem>
	  <para>
<!--
	    Login as the database's operating system user and type:
-->
DBユーザのOSアカウントでログインし、以下を実行します。
	    <programlisting>
            pg_md5 --md5auth --username=<literal>your_username</literal> <literal>your_passwd</literal>
	    </programlisting>
<!--
            user name and md5 encrypted password are registered into
            pool_passwd.  If pool_passwd does not exist yet, pg_md5
            command will automatically create it for you.  The format
            of pool_passwd
            is <literal>username:encrypted_passwd</literal>.
-->
>md5により暗号化されたユーザ名とパスワードがpool_passwdに登録されます。
pool_passwdがまだ存在しなければ、pg_md5コマンドは、自動的にpgpool.confと同じディレクトリ内にpool_passwdwを作成します。
pool_passwdのフォーマットは、<literal>username:encrypted_passwd</literal>です。
	  </para>
	</listitem>

	<listitem>
	  <para>
<!--
	    You also need to add an appropriate md5 entry to
            pool_hba.conf.  See Setting up pool_hba.conf for client
            authentication (HBA) for more details.
-->
また、pool_hba.confに適当なmd5のエントリを作成する必要があります。
詳細は<xref linkend="auth-pool-hba-conf">を見てください。
	  </para>
	</listitem>

	<listitem>
	  <para>
<!--
            Please note that the user name and password must be
            identical to those registered
            in <productname>PostgreSQL</productname>.
-->
pool_passwdに登録するパスワードは、<productname>PostgreSQL</productname>に登録したパスワードと完全に同じでなければなりません。
	  </para>
	</listitem>

	<listitem>
	  <para>
<!--
            After changing md5 password (in both pool_passwd and
            PostgreSQL of course), you need to
            execute <application>pgpool reload</application>.
-->
md5パスワード（もちろんpool_passwdとPostgreSQLの両方）を変更したら、pgpool reload を実行してください。
	  </para>
	</listitem>
      </orderedlist>

    </listitem>
   </varlistentry>

   <varlistentry>
<!--
    <term>Large objects</term>
-->
    <term>ラージオブジェクト</term>
    <listitem>
      <para>
<!--
	In streaming replication
	mode, <productname>Pgpool-II</productname> supports large
	objects.
-->
ストリーミングレプリケーションモードでは、<productname>Pgpool-II</productname>はラージオブジェクトをサポートしています。
      </para>
      <para>
<!--
	In native replication
	mode, <productname>Pgpool-II</productname> supports large
	objects if the backend
	is <productname>PostgreSQL</productname> 8.1 or later.  For
	this, you need to enable lobj_lock_table directive
	in <filename>pgpool.conf</filename>.  Large object replication
	using backend function <function>lo_import</function> is not
	supported, however.
-->
ネィティブレプリケーションモードでは、<productname>PostgreSQL</productname> 8.1以降ならばラージオブジェクトをサポートします。
その際には、<filename>pgpool.conf</filename>のlobj_lock_tableを有効にしてください。
なお、バックエンド関数の<function>lo_import</function>を使ったラージオブジェクトのレプリケーションはサポートされていません。
      </para>
      <para>
<!--
	In other mode, including Slony mode, large
	objects are not supported.
-->
Slonyモードも含め、その他のモードではラージオブジェクトはサポートされていません。
      </para>
    </listitem>
   </varlistentry>

   <varlistentry>
<!--
    <term>Temporary tables in master/slave mode</term>
-->
    <term>一時テーブル</term>
    <listitem>
      <para>
<!--
	Creating/inserting/updating/deleting temporary tables are
	always executed on the master (primary) in master slave mode.
	SELECT on these tables is executed on master as well.  However
	if the temporary table name is used as a literal in SELECT,
	there's no way to detect it, and the SELECT will be load
	balanced.  That will trigger a "not found the table" error or
	will find another table having same name.  To avoid the
	problem, use /*NO LOAD BALANCE*/ SQL comment.
-->
一時テーブルの作成、挿入、更新、削除は、常にマスター（プライマリ）で実行されます。
テーブルに対するSELECTもマスター上で実行されます。
しかし、一時テーブル名が文字列としてSELECTで使われると、それを検知する方法がないため、SELECTは負荷分散されます。
これにより、「テーブルが見つからない」エラーになったり、同じ名前を持つ別のテーブルを検索することになります。
この問題を回避するには、/*NO LOAD BALANCE*/ SQLコメントを使ってください。
      </para>
      <para>
<!--
	Note that such literal table names used in queries to access
	system catalogs do cause problems described above.  psql's \d
	command produces such that query:
	<programlisting>
SELECT 't1'::regclass::oid;
	</programlisting>
	In such that case <productname>Pgpool-II</productname> always
	sends the query to master and will not cause the problem.
-->
ちなみに、psqlの\dコマンドのように、システムカタログを問い合わせる中で
文字列としてのテーブル名を使っている場合:
	<programlisting>
SELECT 't1'::regclass::oid;
	</programlisting>
pgpool-II 3.0以降ではマスタで検索が行なわれるので、問題になりません。
なぜなら、システムカタログへの検索は常にマスタで行なわれるからです。
      </para>

      <para>
<!--
	Tables created by <command>CREATE TEMP TABLE</command> will be
	deleted at the end of the session by specifying DISCARD ALL in
	reset_query_list if you are using PostgreSQL 8.3 or later.
-->
PostgreSQL 8.3以後を使っているのであれば、<command>CREATE TEMP TABLE</command>によって作成されたテーブルは、reset_query_list中のDISCARD ALLを指定することによってセッションの最後で削除されます。
      </para>
      <para>
<!--
	For 8.2.x or earlier, tables created by <command>CREATE TEMP
	TABLE</command> will not be deleted after exiting a
	session. It is because of the connection pooling which, from
	PostgreSQL's backend point of view, keeps the session
	alive. To avoid this, you must explicitly drop the temporary
	tables by issuing <command>DROP TABLE</command>, or
	use <command>CREATE TEMP TABLE ... ON COMMIT DROP</command>
	inside the transaction block.
-->
8.2.x以前では、<command>CREATE TEMP TABLE</command>によって作成されたテーブルは、セッションを終了した後に削除されません。
PostgreSQLバックエンドから見ると、コネクションプールによってセッションが維持されているからです。
これを回避するには、明示的に<command>DROP TABLE</command>を発行するか、トランザクションブロックの内側で<command>CREATE TEMP TABLE ... ON COMMIT DROP</command>を実施します。
      </para>

    </listitem>
   </varlistentry>

   <varlistentry>
<!--
    <term>Functions, etc. In replication mode</term>
-->
    <term>ネィティブレプリケーションモードにおける関数などの扱い</term>
    <listitem>
      <para>
<!--
	There is no guarantee that any data provided using a
	context-dependent mechanism (e.g. random number, transaction
	ID, OID, SERIAL, sequence), will be replicated correctly on
	multiple backends. For SERIAL, enabling insert_lock will help
	replicating data.  insert_lock also helps SELECT setval() and
	SELECT nextval().
-->
文脈依存の仕組み（たとえば乱数やトランザクションID、OID、SERIAL、シーケンス）を使って提供されるデータが複数のバックエンドに正しくレプリケーションされる保証はありません。
SERIALに対しては、insert_lockを使って対応できます。
SELECT setval()とSELECT nextval()に対してもinsert_lockで対応できます。
      </para>
      <para>
<!--
	INSERT/UPDATE
	using <function>CURRENT_TIMESTAMP</function>, <function>CURRENT_DATE</function>,
	<function>now()</function> will be replicated
	correctly. INSERT/UPDATE for tables
	using <function>CURRENT_TIMESTAMP</function>, <function>CURRENT_DATE</function>,
	<function>now()</function> as their DEFAULT values will also
	be replicated correctly.  This is done by replacing those
	functions by constants fetched from master at query execution
	time.  There are a few limitations however:
-->
<function>CURRENT_TIMESTAMP</function>、<function>CURRENT_DATE</function>、<function>now()</function>を含むINSERT/UPDATEは正しくレプリケーションされます。
<function>CURRENT_TIMESTAMP</function>、<function>CURRENT_DATE</function>、<function>now()</function>をデフォルト値として使うINSERT/UPDATEも正しくレプリケーションされます。
これは、関数を、クエリ実行時にマスターから取得した定数に置き換えることで達成されています。
しかし、いくつか制限事項があります。
      </para>
      <para>
<!--
	In <productname>Pgpool-II</productname> 3.0 or before, the
        calculation of temporal data in table default value is not
        accurate in some cases. For example, the following table
        definition:
-->
<productname>Pgpool-II</productname> 3.0以前では、テーブルのデフォルト値としての時制データが正しく計算されない場合があります。
例として以下のテーブル定義を示します。
	<programlisting>
CREATE TABLE rel1(
  d1 date DEFAULT CURRENT_DATE + 1
)
	</programlisting>
<!--
	is treated the same as:
-->
これは次と同じに扱われます。
	<programlisting>
CREATE TABLE rel1(
  d1 date DEFAULT CURRENT_DATE
)
	</programlisting>
<!--
	<productname>Pgpool-II</productname> 3.1 or later handles
	these cases correctly.  Thus the column "d1" will have
	tomorrow as the default value.  However this enhancement does
	not apply if extended protocols (used in JDBC, PHP PDO for
	example) or PREPARE are used.
-->
<productname>Pgpool-II</productname> 3.1以降はこのケースを正しく扱います。
ですのでd1列はtomorrowがデフォルト値になります。
しかし、この改善は拡張プロトコル（たとえばJDBC、PHP PDO）やPREPAREが使用されている場合には適用されません。
      </para>
      <para>
<!--
	Please note that if the column type is not a temporal one,
	rewriting is not performed. Such example:
-->
列の型が時制ではない場合は書き換えは行われないことに注意してください。
そのような例を示します。
	<programlisting>
foo bigint default (date_part('epoch'::text,('now'::text)::timestamp(3) with time zone) * (1000)::double precision)
	</programlisting>
<!--
	Suppose we have the following table:
-->
以下のテーブルがあるとします。
	<programlisting>
CREATE TABLE rel1(
  c1 int,
  c2 timestamp default now()
)
	</programlisting>
<!--
	We can replicate
-->
	<programlisting>
INSERT INTO rel1(c1) VALUES(1)
	</programlisting>
<!--
    since this turn into
-->
これは以下に書き換えられるものの、
	<programlisting>
INSERT INTO rel1(c1, c2) VALUES(1, '2009-01-01 23:59:59.123456+09')
	</programlisting>
<!--
    However,
-->
	<programlisting>
INSERT INTO rel1(c1) SELECT 1
	</programlisting>
<!--
    cannot to be transformed, thus cannot be properly replicated in the current implementation.
    Values will still be inserted, with no transformation at all.
-->
は変換されません。
ですので現在の実装では正しくレプリケーションされません。
値は挿入されますが、全く変換が行われません。
      </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term>SQL型コマンド</term>
    <listitem>
      <para>
<!--
	SQL type commands</link> cannot
	be used in extended query mode.
-->
<link linkend="sql-commands">SQL型コマンド</link>は、拡張クエリモードでは使用できません。
      </para>
    </listitem>
   </varlistentry>

  </variablelist>
 </para>
</sect1>
