制限事項

pg_terminate_backend()を使ってバックエンドを停止すると、フェイルオーバが起こります。 これは、PostgreSQLが、postmasterの停止と全く同じメッセージをバックエンド停止時に送るためです。 3.6より前のバージョンには回避策はありません。 3.6以降では、この制限は緩和されています。 その関数の引数（プロセスIDです）が定数なら、その関数を使っても安全です。 しかし、拡張プロトコルでは、その関数は使えません。

マルチステートメントSQL(1行の中に複数のSQLが含まれている)は、常にプライマリノード(ストリーミングレプリケーションモードの場合)かマスターノード(それ以外のモード)に送られます。 通常Pgpool-IIはクエリの種類を見て適切なノードにクエリを送りますが、マルチステートメントSQLではこれが適用されません。

レプリケーションモードまたマスタ/スレーブモード時にはtrust、reject、pam認証方式が利用できます。 Pgpool-II 3.0以降では、pool_passwdというファイルを使ってmd5認証も使えます。 Pgpool-II 4.0以降では、scram-sha-256、cert、clear text password認証も使えます。 pool_passwdはデフォルトの認証ファイル名です。 md5認証を有効にする手順を示します。

1. DBユーザのOSアカウントでログインし、以下を実行します。

               pg_md5 --md5auth --username=your_username your_passwd
   	    

   ユーザ名とmd5により暗号化されたパスワードがpool_passwdに登録されます。 pool_passwdがまだ存在しなければ、pg_md5コマンドは、自動的にpgpool.confと同じディレクトリ内にpool_passwdを作成します。 pool_passwdのフォーマットは、username:encrypted_passwdです。

2. また、pool_hba.confに適当なmd5のエントリを作成する必要があります。 詳細は項6.1を見てください。

3. pool_passwdに登録するパスワードは、PostgreSQLに登録したパスワードと完全に同じでなければなりません。

4. md5パスワード（もちろんpool_passwdとPostgreSQLの両方）を変更したら、pgpool reload を実行してください。

ストリーミングレプリケーションモードでは、Pgpool-IIはラージオブジェクトをサポートしています。

ネィティブレプリケーションモードでは、PostgreSQL 8.1以降ならばラージオブジェクトをサポートします。 その際には、pgpool.confのlobj_lock_tableを有効にしてください。 なお、バックエンド関数のlo_importを使ったラージオブジェクトのレプリケーションはサポートされていません。

Slonyモードも含め、その他のモードではラージオブジェクトはサポートされていません。

一時テーブルの作成、挿入、更新、削除は、常にマスター（プライマリ）で実行されます。 テーブルに対するSELECTもマスター上で実行されます。 しかし、一時テーブル名が文字列としてSELECTで使われると、それを検知する方法がないため、SELECTは負荷分散されます。 これにより、「テーブルが見つからない」エラーになったり、同じ名前を持つ別のテーブルを検索することになります。 この問題を回避するには、/*NO LOAD BALANCE*/ SQLコメントを使ってください。

ちなみに、psqlの\dコマンドのように、システムカタログを問い合わせる中で 文字列としてのテーブル名を使っている場合:

SELECT 't1'::regclass::oid;
	

pgpool-II 3.0以降ではマスタで検索が行なわれるので、問題になりません。 なぜなら、システムカタログへの検索は常にマスタで行なわれるからです。

PostgreSQL 8.3以後を使っているのであれば、CREATE TEMP TABLEによって作成されたテーブルは、reset_query_list中のDISCARD ALLを指定することによってセッションの最後で削除されます。

8.2.x以前では、CREATE TEMP TABLEによって作成されたテーブルは、セッションを終了した後に削除されません。 PostgreSQLバックエンドから見ると、コネクションプールによってセッションが維持されているからです。 これを回避するには、明示的にDROP TABLEを発行するか、トランザクションブロックの内側でCREATE TEMP TABLE ... ON COMMIT DROPを実施します。

文脈依存の仕組み（たとえば乱数やトランザクションID、OID、SERIAL、シーケンス）を使って提供されるデータが複数のバックエンドに正しくレプリケーションされる保証はありません。 SERIALに対しては、insert_lockを使って対応できます。 SELECT setval()とSELECT nextval()に対してもinsert_lockで対応できます。

CURRENT_TIMESTAMP、CURRENT_DATE、now()を含むINSERT/UPDATEは正しくレプリケーションされます。 CURRENT_TIMESTAMP、CURRENT_DATE、now()をデフォルト値として使うINSERT/UPDATEも正しくレプリケーションされます。 これは、関数を、クエリ実行時にマスターから取得した定数に置き換えることで達成されています。 しかし、いくつか制限事項があります。

Pgpool-II 3.0以前では、テーブルのデフォルト値としての時制データが正しく計算されない場合があります。 例として以下のテーブル定義を示します。

CREATE TABLE rel1(
  d1 date DEFAULT CURRENT_DATE + 1
)
	

これは次と同じに扱われます。

CREATE TABLE rel1(
  d1 date DEFAULT CURRENT_DATE
)
	

Pgpool-II 3.1以降はこのケースを正しく扱います。 ですのでd1列はtomorrowがデフォルト値になります。 しかし、この改善は拡張プロトコル（たとえばJDBC、PHP PDO）やPREPAREが使用されている場合には適用されません。

列の型が時制ではない場合は書き換えは行われないことに注意してください。 そのような例を示します。

foo bigint default (date_part('epoch'::text,('now'::text)::timestamp(3) with time zone) * (1000)::double precision)
	

以下のテーブルがあるとします。

CREATE TABLE rel1(
  c1 int,
  c2 timestamp default now()
)
	

INSERT INTO rel1(c1) VALUES(1)
	

これは以下に書き換えられるものの、

INSERT INTO rel1(c1, c2) VALUES(1, '2009-01-01 23:59:59.123456+09')
	

INSERT INTO rel1(c1) SELECT 1
	

は変換されません。 ですので現在の実装では正しくレプリケーションされません。 値は挿入されますが、全く変換が行われません。

SQL型コマンドは、拡張クエリモードでは使用できません。

現在の実装では、クライアントとPostgreSQLの間でマルチバイト文字の変換処理を行いません。 クライアントエンコーディング、バックエンドノードのサーバエンコーディングを一致させるようにしてください。

マルチステートメント（';'で区切って複数の文をまとめたSQL）をPgpool-IIが正しく処理することができません。 必ず文を分けて送信してください。 なお、psqlを使ってPgpool-IIに接続した場合は、psql内部でマルチステートメントを分解し、1つずつ送信するので、実際には問題になりません。

pgpool-II では libpq をリンクします。 libpq のバージョンは 2.0 の場合、configureに失敗します。 必ず libpq 3.0 以降(PostgreSQL 7.4以降)をリンクするようにしてください。 マルチステートメント（';'で区切って複数の文をまとめたSQL）をPgpool-IIが正しく処理することができません。 必ず文を分けて送信してください。