「TODO」の版間の差分

提供: pgpool Wiki
移動先: 案内、 検索
(→‎Allow to load balance even in an explicit transaction in replication mode)
(マルチステートメントクエリ実装上の問題を追記。)
 
(2人の利用者による、間の5版が非表示)
1行目: 1行目:
 
__FORCETOC__
 
__FORCETOC__
  
−
== Pgpool-II TODO list ==
+
== Pgpool-II TODO リスト ==
  
−
=== Ability to load balance based on Client IP ===
+
=== クライアント IP に基づいたロードバランスができるようにしてほしい ===
−
: From bugid 26:  I have recently moved a database from Mysql to postgresql 9.1.5 which is behind a pgpool-II-3.1.4 . Everything went fine until i observed that some "tickets" are not created correctly by the application (OTRS) that populate the database.
+
:bugtrack #26:  私は最近 Mysql から pgpool-II-3.1.4 を利用した PostgreSQL 9.1.5 にデータベースを移行しました。データベースにデータを投入するアプリケーション (OTRS) が、ある「チケット」を正確に作成していないことを私が発見をするまで、全てはうまくいっていました。
−
: After some debugging i found/guess that the problem is the following:
+
: いくつかのデバッグの後、私は問題は以下の通りであると推測しました。
−
: when a cron job wants to create a ticket he has to insert info in abut 10 tables, and i guess that the 2-nd, 3-rd ... inserts depends on the first. The problem was that this operation is not performed transactionally so after the first insert, when the app tries to perform the other inserts, first tries to select "the first insert", but this first insert is still not propagated to all nodes, and the error occurs.
+
: cron ジョブがチケットを作成しようとすると、そのジョブは 10 前後のテーブルに情報をインサートする必要があります。そして、私は 2 番目、 3 番目以降のインサートは、 1 番目の処理に依存しているのではないかと思います。問題は、この操作がトランザクションに則していないないということです。そのため、 1 番目のインサートの後にアプリケーションが残りのインサートを実行しようと試みた時に、はじめに「1 番目のインサート」を参照しようとします。しかし、 1 番目のインサートはまだすべてのノードに伝搬しておらず、エラーが発生するのです。
−
: I`m aware of the fact that if this entire operation would be performed transactionally (only on master) the issue is solved, but unfortunately i cannot modify the app.
+
: そこで、私は pgpool に対して、「この IP からはどんなリクエストもロードバランスしない」といったような何らかの伝達手段があるかどうか知りたいです。
−
: So i want to know if there is any way that i can tell to pgpool something like :
+
: 追伸、一時的に私は荷重因子を 2 番目と 3 番目の PostgreSQL サーバに設定しました。マスターのみから読み書きが行われるので問題なく動作しています。
−
: any request from this ip do not load balance.
 
  
−
: PS. temporary i have set the weight factor to 0 to the 2-nd and 3-rd postgresql slaves and it behaves ok, because reads and writes only from master.
+
=== ストリーミングレプリケーションの master/slave モードの設定でノードを自動的に再アタッチしてほしい ===
 +
:bugtrack #17: ストリーミングレプリケーションの master/slave モードの設定に、ノートがマスターの最新状態 (0 bytes behind) であったら、自動的にノードが再アタッチできるようなオプションがあると良いかもしれません。小規模ネットワークの停止によって、スレーブノードが pgpool から切り離されたままスレーブノードがマスターと同期して最新状態になっていることがよくあります。pgpool はすでにマスターの背後に何台のスレーブが存在するか分かっているので、それほど困難な改良ではないと思われますが？
  
−
=== Automatically reattach a node in streaming master/slave configuration ===
+
=== クライアントエンコーディングが使えるようにしてほしい ===
−
:In streaming master/slave configuration there could be an option to automatically reattach a node if it's up-to-date with the master (0 bytes behind). It often happens that due to minor network outage a slave node is dropped off from pgpool and stays down even if the the node has resumed replication with master and is up-to-date.pgpool already knows how much slave is behind master so i guess this wouldn't be too difficult to implement? (from bugtrack #17)
+
: pgpool に接続するクライアントが PostgreSQL サーバと異なるエンコーディングを使えたら嬉しいです。
 +
: この改良を行うためには、パーサーが Shift_JIS のような安全でないエンコーディングを扱えるようにする必要があります。psql は各マルチバイト文字の 2 バイト目を変換してパーサーに渡しています。私達はこの戦略を利用することができます。
  
−
=== Allow to use client encoding ===
+
=== フェイルオーバー後であっても、参照クエリをスタンバイのみに送信できるようにしてほしい ===
−
:It would be nice if pgpool client could use encoding which different from PostgreSQL server encoding.
+
: 私達は pgpool-II が参照クエリをプライマリに送信しないように設定できます。しかしながら、フェイルオーバー後では、ノードの役割が変わってしまうことがあります。
−
: To implement this, the parser should be able to handle "unsafe" encodings such as Shift_JIS. psql replaces second byte of each multibyte character to fool the parser. We could hire similar strategy.
+
: この問題を解決するには、フェイルオーバーの発生に関係なく、スタンバイに参照クエリを送信するようにする新しいフラグが必要です ([pgpool-general: 1621] backend weight after failover) 。
  
−
=== Send read query only to standbys even after fail over ===
+
=== マルチステートメントなクエリを認識してほしい ===
−
: We can configure pgpool-II to not send read queries to the primary. However after a fail over, the role of the node could be changed.
+
: ドキュメントによると、 pgpool-II はマルチステートメントなクエリ (BEGIN;SELECT 1;END) を認識しません。 Pgpool-II は 最初のクエリ（この場合は "BEGIN"）だけをパースし、処理を決定します。
−
: To solve the problem, we need new flag to specify that read queries always are sent to standbys regardless the fail over ([pgpool-general: 1621] backend weight after failover).
+
: もちろん、これは様々の問題を引き起こすでしょう。pgpool-II がマルチステートメントなクエリの各要素を理解できるようになると嬉しいです。
 +
: 実装上の問題は、マルチステートメントのバックエンドでの扱いにあります。たとえば、BEGIN;SELECT 1;ENDに対してバックエンドは、BEGIN、SELECT、ENDに対してそれぞれCommand Completeを返しますが、Ready for queryは最後に1度しか返しません。したがって、psqlのように単純にBEGIN, SELECT 1, END を分解しただけではうまく処理できません。
  
−
=== Recognize multi statemnet queries ===
+
=== レプリケーションモード時に、カーソルの宣言がロードバランスされずに全ての DB ノードに送信される ===
−
: As stated in the document, pgpool-II does not recognize multi statement queries correctly (BEGIN;SELECT 1;END). Pgpool-II only parses the first element of the query ("BEGIN" in this case) and decides how to behave.
+
: レプリケーションモード時に DECLARE..FETCH が全ての DB ノードに送信されます。これは SELECT 文に FOR UPDATE/FOR SHARE が付いているからでしょう。
−
: Of course this will bring various problems. It would be nice if we could understand the each part of the multi statement queries.
+
: pgpool-II が SELECT 文に FOR UPDATE/FOR SHARE が使われているかどうかを確認し、使われてなければロードバランスを行う（もしくはロードバランスを使用不可にしていたらマスターノードのみに送信する）ようになると嬉しいです。
 +
: psql を含んだアプリケーションは SELECT 文にカーソルを使うことができることに注意してください。例えば、PostgreSQL 8.2 からは "\set FETCH_COUNT n" が実行されると psql は無条件に "_psql_cursor" というカーソルを使います。
  
−
=== Cursor statements are not load balanced, sent to all DB nodes in replication mode ===
+
=== IPV6 ネットワークをサポートしてほしい ===
−
: DECLARE..FETCH are sent to all DB nodes in replication mode. This is because the SELECT might come with FOR UPDATE/FOR SHARE.
+
: これは当然のリクエストです。
−
: It would be nice if pgpool-II checks if the SELECT uses FOR UPDATE/FOR SHARE and if not, enable load balance (or only sends to the master node if load balance is disabled).
 
−
: Note that some applications including psql could use CURSOR for SELECT. For example, from PostgreSQL 8.2, if "\set FETCH_COUNT n" is executed, psql unconditionaly uses a curor named "_psql_cursor".
 
  
−
=== Support IPV6 network ===
+
=== PostgreSQL の例外処理をインポートしてほしい ===
−
: This is an obvious requirement.
+
: PostgreSQL の例外処理 (elog family) は、コードをシンプルで頑強にできるとても良いツールです。 pgpool もこれが使えるようになると嬉しいです。
  
−
=== Import PostgreSQL's execption handling ===
+
=== watchdog 有効時は仮想 IP インターフェースの不正ダウンに対応してほしい ===
−
: PostgreSQL's exception handling (elog family) is pretty good tool to make codes to be simple and robust. It would be nice if pgpool could use this.
+
: 仮想 IP インターフェースが手動の ifconfig などによって不正に終了すると、VIP を操作することができなくなり、クライアントは pgpool-II に接続できなくなります。アクティブな pgpool の watchdog はインターフェースか VIP を監視し、不正な終了に対応すべきです。
  
−
=== Handle abnormal down of virtual IP interface when watchdog enabled ===
+
=== オンディスを用いたクエリキャッシュを削除してほしい ===
−
: When virtual IP interface is dropped abnormally by manual ifconfig etc., there are no one holding VIP, and clients aren't able to connect pgpool-II. Watchdog of active pgpool should monitor the interface or VIP, and handle its down.
+
: ディスクを用いたクエリキャッシュはほとんど誰も使っておらず、キャッシュの無効化が自動でないといった厳しい制限があります。オンメモリクエリキャッシュが実装されたので、この機能はもはや時代遅れです。私達はこの機能を削除すべきです (これは git のマスターブランチに存在しており、 3.4.0 でも現れるでしょう）。
  
−
=== Remove on disk query cache ===
+
=== 特定の場合では、トランザクション内で作成されたクエリキャッシュを無効にすべきではない ===
−
: Old on disk query cache has almost 0 user and has sevior limitation, including no automatic cache invalidation. This has been already obsoleted since on memory query cache implemented. We should remove this.
+
: あるトランザクション内で作成されたテーブル t1 のクエリキャッシュが、同一トランザクション内で t1 を対象とした DML 文を含んでコミットされた時に削除されます。明らかに、特定の場合にはこれはやり過ぎです。:
−
 
 
−
=== Do not invalidate query cache created in a transaction in some cases ===
 
−
: Currently new query cache for table t1 created in a transaction is removed at commit if there's DMLs which touch t1 in the same transaction. Apparently this is overkill for same cases:
 
 
  BEGIN;
 
  BEGIN;
 
  INSERT INTO t1 VALUES(1);
 
  INSERT INTO t1 VALUES(1);
 
  SELECT * FROM t1;
 
  SELECT * FROM t1;
 
  COMMIT;
 
  COMMIT;
−
: To enhance this, we need to teach pgpool-II about "order of SELECTs and DMLs.".
+
: これを修正するには、私達は DML と SELECT の順序を pgpool-II に教える必要があります。
 +
 
 +
=== pool_config.c のメモリリークを修正してほしい ===
 +
: pgpool.conf のパース処理を担っているモジュールにメモリリークがあります。 大抵の場合、 pgpool は起動時に一度 pgpool.conf を読み込み、これはそれほど大きな問題ではありません。しかしながら、 pgpool.conf の再読み込みはメモリリークを起こし、これは間違いなく問題です。 valgrind などのメモリチェックツールを使った場合ももまた、多くのエラーメッセージを誘発し、非常に煩わしいです。したがって、将来的にこの問題が修正されると嬉しいです。
 +
 
 +
=== SET コマンドを追加してほしい ===
 +
: Pgpool の特定の SET コマンドが役に立つと思います。例えば、"SET debug = 1" を使うとオンザフライで、あるセッションのデバック情報を生み出すといったような。
  
−
=== Fix memory leak in pool_config.c ===
+
=== 一つのヘッダファイルにエラーコードの定義をまとめてほしい ===
−
: The module in charge of parsing pgpool.conf has memory leak problem. Usually pgpool reads pgpool.conf just once at the start up time, it is not a big problem. However reloading pgpool.conf will leak memory and definitely a problem. Also using memory leak check tools like valgrind emit lots of error messages and very annoying. So it would be nice to fix the problem in the future.
+
: 今のところ、pool_send_{error,fatal}_message() など (例えば "XX000", "XX001", "57000") で使われている大部分のエラーコードは、異なるソースにハードコードされている。これらは一つのヘッダーにまとめて定数として定義されるべきです。
  
−
=== Add SET commnad ===
+
=== ヘルスチェックプロセスを別プロセスにしてほしい ===
−
: Pgpool specific SET command would be usefull. For example, using "SET debug = 1" could produce debug info on the fly for particular session.
+
: メインプロセスをさらに安定させるために、ヘルスチェックの役割を持ったプロセスを分割してくれたら嬉しいです。
  
−
=== Add testing framework ===
+
== すでに完了した TODO ==
−
: PostgreSQL has nice regression test suite. It would be nice if pgpool-II has similar test suite. Problem is, such a suite could be very complex system because it should include not only pgpool-II itself, but also multiple PostgreSQL instances. Also don't forget about "watchdog". Even such a test suite should be able to manage multiple pgpool-II instances.
 
  
−
=== Allow to load balance even in an explicit transaction in replication mode ===
+
=== watchdog プロセスが不正に終了したら再起動してほしい ===
−
: Currently load balance in an explicit transaction is only allowed in master-slave mode. It should be allowed in the replication mode as well.
+
: pgpool の main が、watchdog プロセスが不正に終了した場合に watchdog プロセスを再起動してくれると嬉しいです。
  
−
== TODOs already done ==
+
=== スタンバイの pgpool 起動時に watchdog でバックエンドノードの情報を同期してほしい ===
 +
: 例えば、 あるノードがアクティブな pgpool から切り離されてからスタンバイの pgpool が起動した場合、スタンバイの pgpool はノードが切り離されたことに気が付きません。スタンバイの pgpool は他の pgpool からノード情報を取得すべきです。
  
−
=== Restart watchdog process when it abnormaly exits ===
+
=== failover.sh が複数の pgpool から実行されるのを避けるようにしてほしい  ===
−
: It would be nice for pgpool main to restart watchdog process when it dies abormaly.
+
: watchdog を用いたマスタースレーブモードにおいて、バックエンド DB がダウンした時に全ての pgpool が failover.sh を実行します。これはおそらく何か悪いことを引きこすかもしれません。
−
: (Nagata is working on this for pgpool-II 3.3)
 
  
−
=== Synchronize backend nodes information with watchdog when standby pgpool starts up ===
+
=== プライマリノード検索のタイムアウト時間を設定する新しいパラメータを追加してほしい ===
−
: For example, when a certain node is detached from active pgpool and then standby pgpool starts up, the standby pgpool can't recognized that the node is detached. Standby pgpool should get information about node information from other pgpool.
+
: pgpool-II はフェイルオーバーの後でプライマリノードを検索するために "recovery_timeout" を使います。これは設定値の乱用なので、私達はプライマリノード検索用の新しいパラメータを追加すべきです。
  
−
=== Avoid multiple pgpools from executing failover.sh simultaneously.  ===
+
=== レプリケーションモード時に、明示的なトランザクションであってもロードバランスしてほしい ===
−
: In master-slave mode with watchdog, when a backend DB is down, all pgpools execute failover.sh. It might cause something wrong.
+
: 今のところ、明示的なトランザクションのロードバランスはマスタースレーブモードでしかできません。レプリケーションモードもできるべきです。
−
: (Nagata is working on this for pgpool-II 3.3)
 
  
−
=== Add new parameter for searching primary node timeout ===
+
=== テストフレームワークを追加してほしい ===
−
: pgpool-II uses "recovery_timeout" for searching the primary node timeout after failover. Since this is an abuse of the parameter, we should add new parameter for searching the primary node.
+
: PostgreSQL はすばらしいリグレッションテストスイートを持っています。pgpool-II も同様のテストスイートがあると嬉しいです。問題は、そのようなスイートは pgpoo-II 自身だけでなく複数の PostgreSQL インスタンスも含めるべきなので、とても複雑なシステムになってしまうということです。watchdog のことも忘れてはいけません。そのようなテストスイートであっても、複数の pgpool-II インスタンスを扱えるようにしなければいけません。

2014年1月28日 (火) 02:18時点における最新版


目次

Pgpool-II TODO リスト

クライアント IP に基づいたロードバランスができるようにしてほしい

bugtrack #26: 私は最近 Mysql から pgpool-II-3.1.4 を利用した PostgreSQL 9.1.5 にデータベースを移行しました。データベースにデータを投入するアプリケーション (OTRS) が、ある「チケット」を正確に作成していないことを私が発見をするまで、全てはうまくいっていました。
いくつかのデバッグの後、私は問題は以下の通りであると推測しました。
cron ジョブがチケットを作成しようとすると、そのジョブは 10 前後のテーブルに情報をインサートする必要があります。そして、私は 2 番目、 3 番目以降のインサートは、 1 番目の処理に依存しているのではないかと思います。問題は、この操作がトランザクションに則していないないということです。そのため、 1 番目のインサートの後にアプリケーションが残りのインサートを実行しようと試みた時に、はじめに「1 番目のインサート」を参照しようとします。しかし、 1 番目のインサートはまだすべてのノードに伝搬しておらず、エラーが発生するのです。
そこで、私は pgpool に対して、「この IP からはどんなリクエストもロードバランスしない」といったような何らかの伝達手段があるかどうか知りたいです。
追伸、一時的に私は荷重因子を 2 番目と 3 番目の PostgreSQL サーバに設定しました。マスターのみから読み書きが行われるので問題なく動作しています。

ストリーミングレプリケーションの master/slave モードの設定でノードを自動的に再アタッチしてほしい

bugtrack #17: ストリーミングレプリケーションの master/slave モードの設定に、ノートがマスターの最新状態 (0 bytes behind) であったら、自動的にノードが再アタッチできるようなオプションがあると良いかもしれません。小規模ネットワークの停止によって、スレーブノードが pgpool から切り離されたままスレーブノードがマスターと同期して最新状態になっていることがよくあります。pgpool はすでにマスターの背後に何台のスレーブが存在するか分かっているので、それほど困難な改良ではないと思われますが？

クライアントエンコーディングが使えるようにしてほしい

pgpool に接続するクライアントが PostgreSQL サーバと異なるエンコーディングを使えたら嬉しいです。
この改良を行うためには、パーサーが Shift_JIS のような安全でないエンコーディングを扱えるようにする必要があります。psql は各マルチバイト文字の 2 バイト目を変換してパーサーに渡しています。私達はこの戦略を利用することができます。

フェイルオーバー後であっても、参照クエリをスタンバイのみに送信できるようにしてほしい

私達は pgpool-II が参照クエリをプライマリに送信しないように設定できます。しかしながら、フェイルオーバー後では、ノードの役割が変わってしまうことがあります。
この問題を解決するには、フェイルオーバーの発生に関係なく、スタンバイに参照クエリを送信するようにする新しいフラグが必要です ([pgpool-general: 1621] backend weight after failover) 。

マルチステートメントなクエリを認識してほしい

ドキュメントによると、 pgpool-II はマルチステートメントなクエリ (BEGIN;SELECT 1;END) を認識しません。 Pgpool-II は 最初のクエリ（この場合は "BEGIN"）だけをパースし、処理を決定します。
もちろん、これは様々の問題を引き起こすでしょう。pgpool-II がマルチステートメントなクエリの各要素を理解できるようになると嬉しいです。
実装上の問題は、マルチステートメントのバックエンドでの扱いにあります。たとえば、BEGIN;SELECT 1;ENDに対してバックエンドは、BEGIN、SELECT、ENDに対してそれぞれCommand Completeを返しますが、Ready for queryは最後に1度しか返しません。したがって、psqlのように単純にBEGIN, SELECT 1, END を分解しただけではうまく処理できません。

レプリケーションモード時に、カーソルの宣言がロードバランスされずに全ての DB ノードに送信される

レプリケーションモード時に DECLARE..FETCH が全ての DB ノードに送信されます。これは SELECT 文に FOR UPDATE/FOR SHARE が付いているからでしょう。
pgpool-II が SELECT 文に FOR UPDATE/FOR SHARE が使われているかどうかを確認し、使われてなければロードバランスを行う（もしくはロードバランスを使用不可にしていたらマスターノードのみに送信する）ようになると嬉しいです。
psql を含んだアプリケーションは SELECT 文にカーソルを使うことができることに注意してください。例えば、PostgreSQL 8.2 からは "\set FETCH_COUNT n" が実行されると psql は無条件に "_psql_cursor" というカーソルを使います。

IPV6 ネットワークをサポートしてほしい

これは当然のリクエストです。

PostgreSQL の例外処理をインポートしてほしい

PostgreSQL の例外処理 (elog family) は、コードをシンプルで頑強にできるとても良いツールです。 pgpool もこれが使えるようになると嬉しいです。

watchdog 有効時は仮想 IP インターフェースの不正ダウンに対応してほしい

仮想 IP インターフェースが手動の ifconfig などによって不正に終了すると、VIP を操作することができなくなり、クライアントは pgpool-II に接続できなくなります。アクティブな pgpool の watchdog はインターフェースか VIP を監視し、不正な終了に対応すべきです。

オンディスを用いたクエリキャッシュを削除してほしい

ディスクを用いたクエリキャッシュはほとんど誰も使っておらず、キャッシュの無効化が自動でないといった厳しい制限があります。オンメモリクエリキャッシュが実装されたので、この機能はもはや時代遅れです。私達はこの機能を削除すべきです (これは git のマスターブランチに存在しており、 3.4.0 でも現れるでしょう）。

特定の場合では、トランザクション内で作成されたクエリキャッシュを無効にすべきではない

あるトランザクション内で作成されたテーブル t1 のクエリキャッシュが、同一トランザクション内で t1 を対象とした DML 文を含んでコミットされた時に削除されます。明らかに、特定の場合にはこれはやり過ぎです。:
BEGIN;
INSERT INTO t1 VALUES(1);
SELECT * FROM t1;
COMMIT;
これを修正するには、私達は DML と SELECT の順序を pgpool-II に教える必要があります。

pool_config.c のメモリリークを修正してほしい

pgpool.conf のパース処理を担っているモジュールにメモリリークがあります。 大抵の場合、 pgpool は起動時に一度 pgpool.conf を読み込み、これはそれほど大きな問題ではありません。しかしながら、 pgpool.conf の再読み込みはメモリリークを起こし、これは間違いなく問題です。 valgrind などのメモリチェックツールを使った場合ももまた、多くのエラーメッセージを誘発し、非常に煩わしいです。したがって、将来的にこの問題が修正されると嬉しいです。

SET コマンドを追加してほしい

Pgpool の特定の SET コマンドが役に立つと思います。例えば、"SET debug = 1" を使うとオンザフライで、あるセッションのデバック情報を生み出すといったような。

一つのヘッダファイルにエラーコードの定義をまとめてほしい

今のところ、pool_send_{error,fatal}_message() など (例えば "XX000", "XX001", "57000") で使われている大部分のエラーコードは、異なるソースにハードコードされている。これらは一つのヘッダーにまとめて定数として定義されるべきです。

ヘルスチェックプロセスを別プロセスにしてほしい

メインプロセスをさらに安定させるために、ヘルスチェックの役割を持ったプロセスを分割してくれたら嬉しいです。

すでに完了した TODO

watchdog プロセスが不正に終了したら再起動してほしい

pgpool の main が、watchdog プロセスが不正に終了した場合に watchdog プロセスを再起動してくれると嬉しいです。

スタンバイの pgpool 起動時に watchdog でバックエンドノードの情報を同期してほしい

例えば、 あるノードがアクティブな pgpool から切り離されてからスタンバイの pgpool が起動した場合、スタンバイの pgpool はノードが切り離されたことに気が付きません。スタンバイの pgpool は他の pgpool からノード情報を取得すべきです。

failover.sh が複数の pgpool から実行されるのを避けるようにしてほしい

watchdog を用いたマスタースレーブモードにおいて、バックエンド DB がダウンした時に全ての pgpool が failover.sh を実行します。これはおそらく何か悪いことを引きこすかもしれません。

プライマリノード検索のタイムアウト時間を設定する新しいパラメータを追加してほしい

pgpool-II はフェイルオーバーの後でプライマリノードを検索するために "recovery_timeout" を使います。これは設定値の乱用なので、私達はプライマリノード検索用の新しいパラメータを追加すべきです。

レプリケーションモード時に、明示的なトランザクションであってもロードバランスしてほしい

今のところ、明示的なトランザクションのロードバランスはマスタースレーブモードでしかできません。レプリケーションモードもできるべきです。

テストフレームワークを追加してほしい

PostgreSQL はすばらしいリグレッションテストスイートを持っています。pgpool-II も同様のテストスイートがあると嬉しいです。問題は、そのようなスイートは pgpoo-II 自身だけでなく複数の PostgreSQL インスタンスも含めるべきなので、とても複雑なシステムになってしまうということです。watchdog のことも忘れてはいけません。そのようなテストスイートであっても、複数の pgpool-II インスタンスを扱えるようにしなければいけません。
「https://pgpool.net/mediawiki/jp/index.php?title=TODO&oldid=576」から取得