はじめに

2026年3月、アジア最大級の FOSS カンファレンスである FOSSASIA Summit 2026 が開催され、その併設イベントとして PostgreSQL PGDay が開催されました。
PGDay は PostgreSQL に特化した 1 日カンファレンスで、世界各地から PostgreSQL 開発者・ユーザが集まる技術イベントです。
SRA OSS では昨年も FOSSASIA PGDay に参加しましたが、今年は参加に加え、2名がスピーカーとして登壇しました。本記事では、FOSSASIA および PGDay の概要とともに、SRA OSS からの発表内容を中心にご紹介します。

FOSSASIA Summit および PostgreSQL PGDay について

FOSSASIA Summit は、オープンソースソフトウェアやオープンテクノロジーをテーマとした国際カンファレンスです。
ソフトウェア開発だけでなく、OS、クラウド、データベース、AI、セキュリティなど、幅広い分野のセッションが用意され、アジア圏を中心に世界各国から参加者が集まります。

その中で開催される PostgreSQL PGDay は、PostgreSQL の開発や運用、拡張、エコシステムに焦点を当てたイベントです。PostgreSQL の内部構造、性能チューニング、高可用性、運用、セキュリティなど、実運用に直結するテーマが幅広く扱われました。

SRA OSS からの発表

Pgpool-II による PostgreSQL 高可用性と性能最適化

基盤技術グループのプリンシパルエンジニア でPgpool-II 開発者でもある彭 博（ペン ボ）からは、「Pgpool-II: An Introduction to High-Availability and Performance Optimization for PostgreSQL」と題し、PostgreSQL 高可用性構成における課題と、それを解決する Pgpool-II の役割について紹介しました。

PostgreSQL にはストリーミングレプリケーションなどの仕組みがありますが、自動フェイルオーバー／フェイルバックは標準では提供されておらず、読み書きの振り分けやロードバランシングはアプリケーション側で実装が必要といった課題があります。Pgpool-II はクライアントと PostgreSQL の間に配置されるミドルウェア で、アプリケーションを大きく変更することなく「自動フェイルオーバー」や「クエリのロードバランシング」といった機能を提供することで、これらの課題を解決します。また、「コネクションプーリング」「インメモリクエリキャッシュ」といったパフォーマンス向上機能も提供しています。

さらに、Pgpool-II 自体が単一障害点になることを避けるための「Watchdog 機能」についても解説されました。Watchdog 機能により「複数のPgpool-II ノード間での死活監視」「リーダー選出」「Virtual IP の自動切替」「スプリットブレイン防止」といった仕組みが提供され、Pgpool-II 自体も冗長化可能であることが紹介されました。

pg_ivm: 高速なマテリアライズドビュー更新

技術開発室の主席研究員でPostgreSQLコントリビュータでもある長田悠吾（ながたゆうご）からは、「pg_ivm: Extension for Fast Materialized View Maintenance and Recent Improvements」というタイトルで、自身が開発するPostgreSQL 拡張モジュールである pg_ivm について発表しました。

pg_ivm は増分ビューメンテナンス（Incremental View Maintenance, IVM） という、高速なマテリアライズドビューの更新を実現する機能を提供する拡張です。通常のマテリアライズドビューでは、元テーブルが更新された後には REFRESH MATERIALIZED VIEW によりビュー全体を再計算する必要がありますが、IVM では更新された差分のみを計算してビューに適用することで、更新コストを大きく削減します。

具体的には、この拡張モジュールにより、テーブル更新時に自動かつ高速に更新されるIMMV（Incrementally Maintainable Materialized View）と呼ばれるビューを作成できます。テーブル更新時のオーバーヘッドなどいくつかの考慮点はありますが、これを用いることで、ビューの更新が通常の REFRESH と比べて数百倍高速となるケースも示されました。

また、最近の改善として外部結合ビューへの対応が追加されたほか、将来の機能改善として、（テーブル更新時に自動で行うのではなく）手動によるビューの増分更新や、パーティションテーブル、論理レプリケーションへの対応などが検討されていることも紹介されました。

その他の発表

PGDay では、SRA OSS の発表以外にも、PostgreSQL の現在と将来に関わる多様なセッションが行われました。

基調講演では、PostgreSQL の30年の歴史や、PostgreSQL コミュニティとその貢献方法についての紹介が行われました。PostgreSQL の開発や内部構造に関係する発表としては、PostgreSQL 18 新機能解説や、データベースのメタ情報を格納するシステムカタログを深掘りするセッション、近年のインデックスの改善について解説するセッションがありました。

また、Pgpool-II や pg_ivm 以外にも、クエリ実行を外部の Apache DataFusion クエリエンジンで行える拡張モジュール pg_fusion や、LIKE/ILIKE を用いた文字列のマッチングを高速化するためのインデックス Biscuit といったツールを紹介するセッションもあり、PostgreSQL エコシステムの広がりを感じられるプログラムとなっていました。

おわりに

今年の FOSSASIA PGDay も、PostgreSQL の進化とコミュニティの活発さを改めて実感できるイベントでした。SRA OSS としても、PostgreSQL および Pgpool-II や pg_ivm といったツールの開発と情報発信を通じて、引き続き PostgreSQL コミュニティの発展に貢献していきます。

Pgpool-II 4.7 では、クライアント情報表示機能や、Watchdog と heartbeat receiver のセキュリティ強化、オンラインリカバリの機能が強化されました。また、フロントエンド/バックエンドプロトコルバージョン 3.2 サポートの追加、PostgreSQL 18 への対応も行われました。

Pgpool-II 4.7 の新機能及び変更点は Pgpool-II 公式ドキュメントの以下のページに記載されています。

Pgpool-II 4.7 リリースノート

本記事では、これらの新機能について詳しく紹介します。

クライアント情報を表示するための pcp_proc_info, show pool_pools の機能強化

4.6 までは Pgpool-II 経由で PostgreSQL に接続した場合、PostgreSQL 側からは各クライアントの接続情報を確認することができず、Pgpool-II のネットワークアドレスとポート番号のみしかわかりませんでした。
そのため障害が起きてもどのクライアント接続で障害が発生しているのかを調査することが困難でした。

4.7 からは pcp_proc_info, show pool_pools コマンドで Pgpool-II 経由で接続しているクライアントのホスト名、ポート番号、最後に実行した SQL を参照できるようになりました。

Pgpool-II の子プロセス情報を表示する pcp_proc_info コマンドでは client_host(ホスト名), client_port(ポート番号), statement(最後に実行した SQL) が追加されました。

これにより PostgreSQL からでも Pgpool-II 経由で接続しているクライアントの接続情報や最後に実行したクエリ情報を参照できるようになり障害時などに障害が起きているクライアント接続を調査することが容易になりました。

sraoss@server1:~/setuptest$ pcp_proc_info -p 50001 --verbose
Database : test
Username : sraoss
Start time : 2026-01-08 12:15:18 (0:15 before process restarting)
Client connection count : 1
Major : 3
Minor : 0
Backend connection time : 2026-01-08 12:15:18
Client connection time : 2026-01-08 12:15:18
Client idle duration : 0
Client disconnection time : 2026-01-08 12:16:38
Pool Counter : 1
Backend PID : 20250
Connected : 0
PID : 20195
Backend ID : 0
Status : Wait for connection
Load balance node : 0
client_host : 127.0.0.1
client_port : 54726
statement : SELECT 1;

Pgpool-II のコネクションプールの状態を表示する show pool_pools コマンドにも、client_host(ホスト名), client_port(ポート番号), statement(最後に実行した SQL) が追加されました。

これらの変更で子プロセスやコネクションプーリングの情報とあわせてクライアント情報を参照できるようになりました。

test=# show pool_pools;
 pool_pid |                      start_time                      | client_connection_count | pool_id | backend_id | database | username | backend_connection_time | client_connection_time | client_disconnection_time | client_idle_duration | majorversion | minorversion | pool_counter | pool_backendpid | pool_connected |       status        | load_balance_node |  client_host  | client_port |  statement  
----------+------------------------------------------------------+-------------------------+---------+------------+----------+----------+-------------------------+------------------------+---------------------------+----------------------+--------------+--------------+--------------+-----------------+----------------+---------------------+-------------------+---------------+-------------+-------------
[snip]
 1336537  | 2025-06-24 10:53:35                                  | 0                       | 0       | 0          | test     |  sraoss  | 2025-06-24 10:55:58     | 2025-06-24 10:55:59    |                           | 0                    | 3            | 0            | 1            | 1336703         | 1              | Idle                | 0                 | 192.168.10.11 | 39216       | 
 1336537  | 2025-06-24 10:53:35                                  | 0                       | 0       | 1          | test     |  sraoss  | 2025-06-24 10:55:58     | 2025-06-24 10:55:59    |                           | 0                    | 3            | 0            | 1            | 1336704         | 1              | Idle                | 1                 | 192.168.10.11 | 39216       | select 1;
 1336537  | 2025-06-24 10:53:35                                  | 0                       | 1       | 0          |          |          |                         |                        |                           | 0                    | 0            | 0            | 0            | 0               | 0              | Idle                | 0                 | 192.168.10.11 | 39216       | 
 1336537  | 2025-06-24 10:53:35                                  | 0                       | 1       | 1          |          |          |                         |                        |                           | 0                    | 0            | 0            | 0            | 0               | 0              | Idle                | 0                 | 192.168.10.11 | 39216       | select 1;

pgpool_adm_pcp_proc_info 関数の追加

pgpool_adm エクステンションに、Pgpool-II の子プロセスの情報を表示する pgool_adm_pcp_proc_info 関数が追加されました。 pgpool_adm エクステンションは Pgpool-II 経由でも、あるいは直接 PostgreSQL から呼び出せる関数群です。

pgool_adm_pcp_proc_info で表示される情報は pcp_proc_info コマンドと同様ですが、pgpool_adm エクステンションの関数であるため 、PostgreSQL クライアントからでも呼び出せます。

pgpool_adm を使うメリットは、SQLが使用でき WHERE 句で条件を指定して表示内容を絞り込むことができることです。(pcp コマンドの場合は、出力結果を整形するために OS のコマンドを併用する必要があります。)

導入には以下コマンドで各サーバーで pgpool_adm をインストールしてください。

# 各サーバーで以下を実行してインストール 
$ psql test
test=# CREATE EXTENSION pgpool_adm;

その後 Pgpool-II や PostgreSQL のクライアント上で pgpool_adm_pcp_proc_info を実行します。
connected 列は接続状況を表示(0=接続なし, 1=接続中) しており、今回の例のように WHERE 句に “connected = 1” を指定することで接続中の情報に絞ることもできます。

test=# select * from pcp_proc_info(host => '', port => 11001, username => 'sraoss', password => 'sraoss') where connected = '1';
-[ RECORD 1 ]-------------+----------------------------------------------------------------------------------------------------------------------------
database                  | test
username                  | sraoss
start_time                | 2026-01-08 10:56:08
client_connection_count   | 0
major                     | 3
minor                     | 0
backend_connection_time   | 2026-01-08 10:58:37
client_connection_time    | 2026-01-08 10:58:37
client_idle_duration      | 0
client_disconnection_time | 
pool_counter              | 1
backend_pid               | 14750
connected                 | 1
pid                       | 14585
backend_id                | 0
status                    | Execute command
load_balance_node         | 1
client_host               | 127.0.0.1
client_port               | 59120
statement                 | select * from pcp_proc_info(host => '', port => 11001, username => 'sraoss', password => 'sraoss') where connected = '1';

また pg_stat_activity と組み合わせてより詳細な情報を表示することも可能です。
以下の SQL では pgpool_adm_pcp_proc_info とpg_stat_activity を結合して pgool_adm_pcp_proc_info では取得できない state を pg_stat_activity をから取得しています。
他にも wait_event など pg_stat_activity にしかない情報も同時に取得するなど要件に応じてクライアント情報を取得できます。

test=# SELECT p.username, p.database, p.client_port, s.state, s.wait_event, s.query,
              p.pid as pgpool_pid, s.pid as backend_pid
              FROM pcp_proc_info(host => '', port => 11001,
                                 username => 'sraoss', password => 'sraoss') AS p
              JOIN pg_stat_activity AS s ON s.pid::text = p.backend_pid;
-[ RECORD 1 ]-------------+----------------------------------------------------------------------------------------------------------------------------
username                  | sraoss
 database                 |  test
 client_host              | 192.168.100.101
client_port               | 50001
state                     | active  
query                     | select 1;
pgpool_pid                | 21467
backend_pid               | 21500

ライフチェックログの改善

ライフチェックが開始したとき Watchdog は ライフチェックが開始したことを知らせるログを出力します。
4.6 までは正常に開始したタイミングでしかログが出力されないため、正常に動作しているかを確認するために開始ログが出るまでログを監視する必要があり、またライフチェックが正常に開始していない状況に気づくのが困難でした。

LOG:  watchdog: lifecheck started

4.7 からはライフチェックが開始されるまで定期的にライフチェックが開始していない警告を出力するようになり、ライフチェック開始までログファイルを監視する必要がなくなりました。
間隔は wd_interval × 10 秒です。

WARNING:  watchdog: lifecheck has not started yet

Watchdog と heartbeat receiver のセキュリティ強化

Watchdog と heartbeat receiver が受け付けるアドレスを制限することができるようになりました。

4.6 まではいずれのプロセスも、ホストが持つすべてのネットワークアドレスへの接続を受け付けていました。

tcp        0      0 0.0.0.0:9000            0.0.0.0:*     LISTEN   3583037/pgpool: watchdog
Tcp6       0      0 :::9000                 :::*          LISTEN   3583037/pgpool: watchdog
Udp        0      0 0.0.0.0:9694            0.0.0.0:*              3583050/pgpool: heartbeat receiver
udp        0      0 0.0.0.0:9694            0.0.0.0:*              3583044/pgpool: heartbeat receiver
udp6       0      0 :::9694                 :::*                   3583044/pgpool: heartbeat receiver
udp6       0      0 :::9694                 :::*                   3583050/pgpool: heartbeat receiver

4.7 からはセキュリティ上の点から hostname, heartbeat_hostname で指定したネットワークアドレスへのみ接続を受け付けるようになりました。

# pgpool.conf 設定例
hostname0 = '192.168.100.50'
wd_port0 = 9000
heartbeat_hostname0 = '192.168.100.101'
heartbeat_port0 = 9694
hostname1 = '192.168.100.60'
wd_port0 = 9000
heartbeat_hostname1 = '192.168.100.102'
heartbeat_port1 = 9694
hostname2 = '192.168.100.70'
wd_port0 = 9000
heartbeat_hostname2 = '192.168.100.103'
heartbeat_port2 = 9694

tcp        0      0 192.168.100.50:9000    0.0.0.0:*     LISTEN      41636/pgpool: watchdog
tcp        0      0 192.168.100.50:9000    0.0.0.0:*     LISTEN      41638/pgpool: watchdog
udp        0      0 192.168.100.101:9694   0.0.0.0:*                 41649/pgpool: heartbeat receiver
udp        0      0 192.168.100.101:9694   0.0.0.0:*                 41650/pgpool: heartbeat receiver

もし他ノードから hostname, heartbeat_hostname で指定したネットワークアドレス以外へ heartbeat を送る設定とすると以下メッセージのように lifecheck に失敗します。
4.7 へ移行する場合は hostname, heartbeat_hostname で watchdog と heartbeat で LISTEN するソケットを設定し、他ノードから heartbeat を送るソケットを hostname, heatbeat_hostname で指定したネットワークアドレスとしてください。

WARNING:  watchdog: lifecheck has not started yet

また 4.7. 1 ではさらに Watchdog と heartbeat それぞれについて LISTEN するソケットを個別で指定できるようになりました。
これによりノード外部から見えるアドレスと、ノード内部から認識されるアドレスが異なる可能性があるコンテナ環境や、ポートフォワーディングを設定している場合でも、より柔軟に設定できるようになりました。
Watchdog については wd_listen_address によってネットワークアドレスを、wd_listen_port によってポートも指定することができます。
heartbeat についてはそれぞれ wd_heartbeat_listen_addresses, wd_heartbeat_listen_port によって指定できます。
これらのパラメータが設定されているとき hostname, heartbeat_hostname, wd_port, heartbeat_port のローカルの設定は上書きされてソケットが作成されます。

# pgpool.conf 設定例
hostname0 = '192.168.100.50'
wd_port0 = 9000
heartbeat_hostname0 = '192.168.100.101'
heartbeat_port0 = 9694
wd_listen_address = 192.168.100.100
wd_listen_port = 50000
wd_heartbeat_listen_addresses = 102.168.100.110
wd_heartbeat_listen_port = 51000

tcp        0      0 192.168.100.100:50000    0.0.0.0:*     LISTEN      41636/pgpool: watchdog
udp        0      0 192.168.100.110:51000    0.0.0.0:*                 41649/pgpool: heartbeat receiver
udp        0      0 192.168.100.110:51000    0.0.0.0:*                 41650/pgpool: heartbeat receiver

これらのパラメータが導入された背景は、Docker 環境を代表とした TCP 転送ルールを設けているインターフェース間で通信をする際に LISTEN するソケットを転送ルールに合わせて設定したいケースに対応するためです。
例えばノード 0 が IP:192.168.0.0, ポート番号:10000 のソケットに接続しようとし、TCP 転送ルールによってノード 1 の IP:192.168.100.100,ポート番号:20000 のソケットにリダイレクトされる環境の場合、ノード 1 側でリダイレクト後のネットワークアドレス、ポート番号(今回の例では IP:192.168.100.100, ポート番号:20000)に設定することで TCP 転送ルールがある場合でも通信が可能となりました。

オンラインリカバリに使用するデータベースを指定する recovery_database パラメータの追加

オンラインリカバリとは障害が発生して切り離されてしまった PostgreSQL ノードをプライマリに再同期して復帰する処理を各ノードを停止することなく行うことができる機能です。

以前はオンラインリカバリに template1 データベースを使用するようにしていましたが、今回追加された recovery_databse パラメータにオンラインリカバリに使用するデータベースを指定することができるようになりました。

#pgpool.conf の recovery_database を指定
recovery_database = 'postgres'

デフォルト値は postgres になっています。
4.6 以前から移行をする際には recovery_database に指定したデータベースで下記コマンドを実施してオンラインリカバリに必要な関数をインストールしておく必要があります。

psql postgres -c "CREATE EXTENSION pgpool_recovery"

.pcppassファイルからの読み取りに失敗時の挙動改善

.pcppass ファイルは pcp コマンドを実行したときに読み込まれるパスワードファイルです。

4.6 までは pcp コマンド実行時に .pcppass ファイルが未作成かパスワードファイルの権限設定が不適切の場合、エラーで終了していました。
また -d, –debug オプションがないとデバッグ情報が出力されず失敗の原因も特定できませんでした。

FATAL:  authentication failed for user "sraoss"
DETAIL:  username and/or password does not match

失敗後は .pcppass ファイルを適切な権限で作成するか、パスワード入力を受け付けるオプションである -W オプションをつけて pcp コマンドを再実行する必要がありました。

pcp_node_info -p 9898 -W
Password:

4.7 からはエラーを出力して終了するのではなく、クライアントのコマンドプロンプトにフォールバックして引き続きパスワードを入力することができるようになりました。

また WARNING による警告が -d, –debug オプションなく出力される仕様に変更され、読み取りができなかった原因もメッセージから特定することができます。

WARNING: password file ~/.pcppass is not a plain file
WARNING: password file ~/.pcppass has group or world access; permissions should be u=rw (0600) or less

フロントエンド / バックエンドプロトコルバージョン 3.2 サポートの追加

PostgreSQL 18 ではプロトコルバージョン 3.2 に対応し、可変長のキャンセルキーが用いることができるようになりました。
この変更に合わせ、Pgpool-II でもプロトコルバージョン 3.2 を利用できるように改善がされました。

max_protocol_version や PGMAXPROTOCOLVERSION を用いた以下のようなコマンドで 3.2 プロトコルを使用して PostgreSQL のフロントエンドとバックエンドを接続することができます。
バージョンには 3.2 だけでなく PostgreSQL 18 のデフォルトのプロトコルバージョンである 3.0 を指定することもできます。

# max_protocol_version オプションで 3.0 バージョンで接続
psql "host=localhost dbname=test user=sraoss max_protocol_version=3.0 port=11000"

# 環境変数 PGMAXPROTOCOLVERSION に 3.2 を指定して接続
PGMAXPROTOCOLVERSION="3.2" psql -p 11000 test

新規接続時は指定したプロトコルバージョンで接続を確立しますが、コネクションプーリングのキャッシュがある場合は既存のキャッシュに保存されたのプロトコルバージョンを用いて接続を行うため確立済みの接続間でバージョンが異なることによるエラーの心配もありません。

PostgreSQL 18 の SQL パーサの導入

Pgpool-II ではメジャーリリースするたびに、PostgreSQL の最新パーサを移植しています。今回のリリースでは PostgreSQL 18 の新しいパーサを取り込みました。

Pgpool-II の負荷分散機能では、SQL を解析して参照か更新かを判別し、どのノードに振り分けるかを決めています。そのため、PostgreSQL の新バージョンでの SQL の変更に対応するには、SQL パーサを移植する必要があります。

PostgreSQL 18 での SQL のおもな変更点は以下のとおりです。

• 生成列を仮想列として使用可能に
• DML クエリの RETURNING にOLD/NEWのサポートを追加
• 各種制約の追加(例: WITHOUT OVERLAPS、ENFORCED/NOT ENFORCED)

Pgpool-II 4.7 では上記の変更点に対応しています。

logdir パラメータ名を work_dir へ変更

4.6 までは Pgpool-II の起動状態を記述する pgpool_status や memq_lock_file といった管理ファイルを logdir に指定するディレクトリに保存していました。
しかし logdir というパラメータ名はログ関連のファイルを格納するディレクトリの設定パラメータと誤解されやすい問題がありました。

4.7 からはパラメータ名が work_dir へ変更となりました。

logdir のパラメータ自体も引き続き利用することができ、logdir に指定した値が work_dir の設定値へと再設定され Pgpool-II の終了時に以下ワーニングが表示されます。

2026-01-08 11:50:48.193: main pid 18667: WARNING: logdir is changed to work_dir
2026-01-08 11:50:48.193: main pid 18667: DETAIL: if logdir is specified, the value will be set to work_dir

Slony モードの廃止

backend_clustering_mode で指定することができていた Slony モードが廃止されました。

データのレプリケーションを Slony-I が行うクラスタリングモードの一つでしたが、Slony-I は 3 年前からリリースが停止しています。
現在は Slony モードについて積極的に利用するユーザーが見られず、廃止のアナウンスに異議がなかったため 4.7 からは廃止となりました。

Pgpool-II の libpcp ライブラリの名称を libpgpoolpcp に変更

4.7.1 のマイナリリースにて Pgpool-II のライブラリである libpcp の名称を libpgpoolpcp に変更されました。
背景として、RHEL の libpcp ライブラリと Pgpool-II の libpcp ライブラリがコンフリクトする問題があったためです。

おわりに

今回は、Pgpool-II 4.7 の新機能について紹介しました。

Pgpool-II 4.7 では、より実用的で便利な機能が数多く追加・改善されています。PostgreSQL の高可用性構成や負荷分散の実現を検討されている方にとって、Pgpool-II は有力な選択肢です。ぜひこの機会に Pgpool-II の導入をご検討ください。

PostgreSQL は、世界中の開発者や企業が協力することで発展してきたコミュニティベースのオープンソース RDBMSです。SRA OSS は、1996年の PostgreSQL 初版リリースの直後からコミュニティの一員として、PostgreSQL 本体の開発、周辺ツールの開発、コミュニティ運営、ドキュメント翻訳など、多岐にわたって活動を続けてきました。本記事では、2025 年における SRA OSS メンバーのPostgreSQL 本体および関連ツールの開発への貢献内容を紹介します。

SRA OSS 在籍の PostgreSQL Contributors

PostgreSQL コミュニティでは、コード、ドキュメント、議論、コミュニティ活動などを通じ、継続的に貢献している個人を「PostgreSQL Contributor」として認定しています。

現在、SRA OSS には以下5名の PostgreSQL Contributor が在籍しています。なかでも顧問の石井 達夫と取締役の藤井 雅雄は、特に多大な影響を与えてきた Major Contributor として認定されています。また、この２人は PostgreSQL 本体コードへのコミット権限を持つコミッタ（Committer）でもあります。

• Major Contributors（かつ、Committer）
  • 石井 達夫（顧問）
  • 藤井 雅雄 （取締役）
• Contributors
  • 長田 悠吾
  • 鳥越 淳
  • 高塚 遥

2025年の PostgreSQL 開発への貢献

以下では、PostgreSQL コミュニティの Major Contributor かつコミッタである Robert Haas 氏のブログ記事「 Who Contributed to PostgreSQL Development in 2025?」で公開されている解析データを基に、SRA OSS メンバーが行った具体的な PostgreSQL 開発への貢献を紹介します。

なお、公開されているオリジナルデータでは、パッチの作者情報は git のコミットログから自動的に決定されていますが、本記事では、Robert Haas 氏の確認の上で、コミットログをもとに一部のコミットの作者情報を修正したデータを使用しています。

PostgreSQL にコミットされたパッチ

PostgreSQL の開発は、提案されたパッチについてコミュニティで議論・レビューが行われ、その後コミットされることで進められます。

2025年にコミットされたパッチのうち、SRA OSS メンバーが主要作者（中心的にコードを書いた者）として関わったものは以下のとおりです。

メーリングリスト（pgsql-hackers）における議論

PostgreSQL 開発は、主に pgsql-hackers と呼ばれるメーリングリストでの議論を通じて進められます。このメーリングリストの中で、機能改善やバグ修正の提案、パッチの投稿、レビューなど、開発に関するやりとりが日々が行われています。

2025年にSRA OSSメンバーが pgsql-hackers に投稿はした議論数は以下のとおりです。

コミッタの活動

コミッタはパッチをPostgreSQL コードに反映する権限を持っていますが、その際には自分が書いていないパッチについても、その適用可否を慎重に判断して、品質を確保したうえでコミットするという、重要な役割をもっています。

以下は、SRA OSS に在籍するコミッタによる、自分が主要作者でないパッチのコミット実績を集計したものです。

サードパーティーツールの開発

SRA OSS は PostgreSQL 本体だけでなく、関連ツールや拡張モジュールの開発にも取り組むことで、周辺エコシステムの発展に貢献しています。ここでは、SRA OSS が中心開発者として携わる Pgpool-II と pg_ivm の活動について紹介します。

Pgpool-II

Pgpool-IIはPostgeSQL 用のクラスタ管理ツールであり、2025年は 2 回のメジャーリリースと複数のマイナーリリースが行われました。

• Pgpool-II 4.6.0 (2025/02/28)
  • ログ管理とクエリキャッシュ操作のPCPコマンド追加、など
• Pgpool-II 4.7.0 (2025/12/23)
  • フロントエンド/バックエンドプロトコルバージョン3.2サポート
  • watchdogとheartbeat receiverのセキュリティ強化、など
• そのほか、不具合修正を含む計６回のマイナーリリース

pg_ivm

pg_ivm は、マテリアライズドビューの増分メンテナンス機能（Incremental View Maintenance）をPostgreSQL に提供する拡張モジュールです。2025年には以下のリリースが行われました。

• v1.10（2025/03/11）：不具合修正
• v1.11（2025/05/26）：不具合修正
• v1.12（2025/09/04）：PostgreSQL 18 対応
• v1.13（2025/10/20）：外部結合ビューに対応

まとめ

2025 年における SRA OSS のPostgreSQL 本体および関連ツールの開発への貢献を紹介しました。ここで紹介したもの以外にも、日本PostgreSQLユーザ会（JPUG）の運営、ドキュメントの日本語翻訳、ビルドファーム提供など、多面的な活動を通して PostgreSQL コミュニティに貢献しています。

こうした活動を通して、SRA OSS は今後も PostgreSQL とそのエコシステムの発展に貢献し続けていきます。

開催概要

プログラム

Pgpool-IIの歩みと進化 ー 基本機能から最新ユースケースまで

Pgpool-IIはオンプレ用途に限らず、クラウド上での運用やマネージドサービスと組み合わせることで、多様なユースケースで活用できます。それらの代表的なケースと導入メリットを解説します。

また近年は、遠隔地での性能改善など、従来構成では顕在化しにくかった新たな要望も増えています。こうしたユーザニーズに対し、Pgpool-IIがどのように機能強化や改善の取り組みを進めているのか、今後の方向性についてもご紹介します。

講師：株式会社SRA OSS 彭 博（Pgpool-II開発者／コミュニティリーダー）

Pgpool-II 4.7 新機能解説

2025年12月にリリースされたPgpool-II 4.7では、性能向上や構成の柔軟性を高めるための改善が複数盛り込まれています。本セッションでは、4.7の主要な追加・改善点を整理しながら解説します。

講師：株式会社SRA OSS 越野 太基（Pgpool-II開発者）

PostgreSQLを運用中、またはPostgreSQLの情報を収集中の方がお近くにいらっしゃいましたら、ぜひお声がけいただき、皆さまにご参加いただけますと幸いです。よろしくお願いいたします。

本記事では、性能向上やサーバリソースの効率的な活用に役立つコネクションプーリングの仕組みについて解説します。あわせて、運用時に押さえておくべき設定のポイントについても紹介します。

コネクションプーリングとは

データベースへの接続には、ネットワークのハンドシェイクや認証といった初期処理が伴います。そのため、リクエストのたびに接続してすぐに切断するような動作を繰り返すと、システム全体に大きなオーバーヘッドが発生してしまいます。

そこで効果を発揮するのが、コネクションプーリングという仕組みです。この機能では、一度確立したデータベース接続をキャッシュしておき、次回のリクエスト時に再利用することで、接続処理の無駄を省きます。これにより、システム全体のパフォーマンスが向上し、リソースを無駄なく効率的に活用できるようになります。

Pgpool‑II コネクションプーリングの仕組み

Pgpool-II は、ユーザ名・データベース名・プロトコルバージョンなどの接続プロパティが同一であるリクエストに対して、すでに確立された接続を再利用する仕組みを持っています。これにより、毎回の接続処理にかかるコストを削減し、全体の処理効率を高めることができます。

以下は、Pgpool-II コネクションプーリングの基本的な動作の流れです。

1. 起動時に、Pgpool-II の親プロセスは num_init_children で指定された数の子プロセスをあらかじめフォークします。各子プロセスは max_pool の設定値まで接続をキャッシュします。
2. Pgpool-II はクライアントからの接続要求を待ち受けます。
3. いずれかの Pgpool-II の子プロセスが、クライアントからの接続要求を受け取ります。
4. その子プロセスは、保持している接続内に、接続情報 (データベース/ユーザ) の一致するものがあるかどうかを探します。見つかったら再利用します。
5. 見つからなければ、子プロセスは新たに PostgreSQL サーバへ接続し、それをプールに登録します。
   プールに空きスロットがない場合は、最も古い接続を切断し、そのスロットを再利用します。
6. クライアントがセッション終了要求を送るまで、クエリ処理を行います。
7. クライアントが接続を終了します。Pgpool-II はクライアントへの接続をクローズしますが、PostgreSQL への接続を保持します。

主な設定パラメータ

以下は、コネクションプーリングに関連する設定項目です。

PostgreSQL では、接続ごとにプロセスが生成されますが、接続が切断されない限り、そのプロセスが使用するメモリは解放されません。Pgpool-II のコネクションプーリングを使用している場合、クライアントが切断しても PostgreSQL 側の接続は保持され続けるため、そのプロセスが使用するメモリも解放されません。

そのため、もし DB サーバのメモリ使用量が徐々に増加していく事象が発生している場合、Pgpool-II のコネクションプーリングが影響している可能性があります。このような事象やメモリリークのリスクを防ぐために、child_life_time を設定することが推奨されています。ただし、Pgpool-II の子プロセスがアイドル状態になる時間が child_life_time より短い場合、PostgreSQL への接続を終了する機会が得られません。そのため、child_max_connections も併せて設定しておくことで、一定回数の接続処理後に子プロセスを終了させ、より確実に接続とメモリを解放することができます。

設定上の注意点

Pgpool-II は、各 PostgreSQL サーバに対して以下の数の接続を確立する可能性があります。

num_init_children × max_pool

そのため、PostgreSQL 側の max_connections 設定と照らし合わせて、Pgpool-II の接続数を適切に設定する必要があります。

まず、PostgreSQL にはスーパーユーザ用の接続枠が superuser_reserved_connections によって確保されており、これは通常ユーザの接続には使用できません。したがって、Pgpool-II からの接続数は、この予約分を除いた枠内に収まるように調整する必要があります。

また、Pgpool-II はクエリキャンセルを行う際に、既存の接続とは別に新たな接続を PostgreSQL に確立するため、この追加分も接続数として考慮する必要があります。

さらに、Pgpool-II の Watchdog 機能を利用している場合、リーダー切り替えのタイミングで旧リーダーの接続が残ったまま、新しいリーダーが接続を開始するケースもあります。このような状況では一時的に接続数が増加し、PostgreSQL 側の制限を超えてしまうリスクがあります。

これらを踏まえると、Pgpool-II の接続数が PostgreSQL の接続数上限に収まるように、以下の条件を満たすように設計する必要があります。

• クエリキャンセルを考慮しない場合

max_pool × num_init_children × 2 ≤ max_connections − superuser_reserved_connections

• クエリキャンセルを考慮する場合

max_pool × num_init_children × 2 × 2 ≤ max_connections − superuser_reserved_connections

終わりに

今回は Pgpool-II のコネクションプーリング機能について紹介しました。この機能を活用することで、PostgreSQL の接続効率を高め、リソースの最適化が期待できます。Pgpool-II を導入する際は、ぜひコネクションプーリング機能の活用をご検討ください。

Pgpool-II 4.6 では、ロギングコレクター、クエリキャッシュの機能強化がされました。また、バックエンドからのメッセージのログ機能の搭載、PostgreSQL 17 への対応、Watchdog の IPv6 への対応も行われました。

Pgpool-II 4.6 の新機能及び変更点は Pgpool-II 公式ドキュメントの以下のページに記載されています。

Pgpool-II 4.6 リリースノート

本記事では、これらの新機能について詳しく紹介します。

ログのローテーションを指示する新しい PCP コマンド

Pgpool-II には、PostgreSQL のロギングコレクター(logging_collector) と同様のログ収集機能が備わっています。

ロギングコレクターを使ってログを収集する場合、これまではロギングコレクターにシグナルを送ることでしかログのローテーションを行えませんでしたが、pcp_log_rotate コマンドを使用することで Pgpool-II のログファイルを簡単にローテーションできるようになりました。

動作確認のための設定例は以下の通りです。

(pgpool.conf 設定例)
log_destination = 'stderr' 
logging_collector = on 
log_directory = '/var/log/pgpool_log' 
log_filename = 'pgpool-%Y-%m-%d_%H%M%S.log'

log_directory で指定したディレクトリを確認すると、現時点でのログが出力されていることが確認できます。

[root@server1 ~]# ls -l /var/log/pgpool_log/
合計 4
-rw-------. 1 postgres postgres 193 6月 9 16:21 pgpool-2025-06-09_162145.log

その後、 pcp_log_rotate を実行することで新しいログファイルへとローテートされていることが確認できます。

[root@server1 ~]# pcp_log_rotate -h 192.168.100.50  -p 9898 -U pgpool -W
Password:
pcp_log_rotate -- Command Successful

[root@server1 ~]# ls -l /var/log/pgpool_log/
合計 8
-rw-------. 1 postgres postgres 284 6月 9 16:21 pgpool-2025-06-09_162145.log
-rw-------. 1 postgres postgres 193 6月 9 16:21 pgpool-2025-06-09_162159.log

また -s scope オプションによってコマンドの与える影響範囲を指定することができます。サポートされているコマンドスコープは以下です。(デフォルトは local)

• c, cluster : クラスタを構成するすべての Pgpool-II のログファイルをローテーションします。
• l, local : ローカル Pgpool-II のログファイルをローテーションします。

リロードによる logging_collector 関連のパラメータの変更

logging_collector 関連の以下の設定パラメータの変更が、Pgpool-II のリロードで反映されるようになりました。これにより logging_collector の設定の反映のために Pgpool-II の再起動の必要がなくなりました。

• log_truncate_on_rotation
• log_directory
• log_filename
• log_rotation_age
• log_rotation_size
• log_file_mode

リロードで設定が反映されるかの動作確認として log_filename の値を変更したうえで pcp_log_rotate コマンドを実行してログファイルの名前が変更されて出力されるかを確認します。

まず、pgpool.conf を以下の設定に変更し、 Pgpool-II をリロードします。

[root@server1 ~]# vi /etc/pgpool-II/pgpool.conf
#log_filename = 'pgpool-%Y-%m-%d_%H%M%S.log'
log_filename = 'pgpool-%a.log'

[root@server1 ~]# systemctl reload pgpool.service

その後 pcp_rotate_log コマンドを実行すると出力されるログファイルの名前が変更されていることが確認できます。

[root@server1 ~]# ls -l /var/log/pgpool_log/
合計 8
-rw-------. 1 postgres postgres 284  6月 12 09:51 pgpool-2025-06-12_095140.log
-rw-------. 1 postgres postgres 193  6月 12 09:51 pgpool-2025-06-12_095142.log

[root@server1 ~]# pcp_log_rotate -U pgpool -W -h 192.168.100.50
Password:
pcp_log_rotate -- Command Successful
[root@server1 ~]# ls -l /var/log/pgpool_log/
合計 12
-rw-------. 1 postgres postgres 284  6月 12 09:51 pgpool-2025-06-12_095140.log
-rw-------. 1 postgres postgres 411  6月 12 09:52 pgpool-2025-06-12_095142.log
-rw-------. 1 postgres postgres 361  6月 12 09:52 pgpool-Thu.log

クエリキャッシュの強制的な作成

クエリキャッシュは SELECT クエリの実行結果を共有メモリに保存し、同じクエリ(パラメータ、データベース、ユーザ含む)が実行されたら、結果を再利用する機能です。PostgreSQL にアクセスせず、ディスクアクセスもないので極めて高速に問い合わせ結果を返すことができます。

Pgpool-II では、クエリキャッシュは通常自動的に作成されますが、安全性の観点から、immutable でない関数を含むクエリ (たとえば SELECT now();) はキャッシュされない仕様になっています。

以下の実行例では、クエリを実行するたびに結果が変化していることがわかります。

postgres=> SELECT now();
now
-------------------------------
2025-06-12 17:10:27.241885+09
(1 行)

postgres=> SELECT now();
now
-------------------------------
2025-06-12 17:10:29.156295+09
(1 行)

また、ログからも毎回 PostgreSQL にアクセスしていることが確認できます。

2025-06-12 17:10:27.241: psql pid 2628: LOG: DB node id: 1 backend pid: 2644 statement: SELECT now();
2025-06-12 17:10:29.155: psql pid 2628: LOG: DB node id: 1 backend pid: 2644 statement: SELECT now();

それでも、内容を理解したうえでキャッシュを行いたいユースケースが存在することから、今回のリリースではクエリキャッシュを強制的に作成する機能が追加されました。クエリの先頭に /*FORCE QUERY CACHE*/ を付けて実行することで、クエリキャッシュを強制的に作成できるようになります。

以下のようにクエリを実行することで、キャッシュされた時点のタイムスタンプが返されていることが確認できます。このキャッシュは Pgpool-II を再起動するまで保持されます。

postgres=> /*FORCE QUERY CACHE*/SELECT now();
now
------------------------------
2025-06-12 17:14:47.297804+09
(1 行)

postgres=> /*FORCE QUERY CACHE*/SELECT now();
now
------------------------------
2025-06-12 17:14:47.297804+09
(1 行)

さらに、ログにもキャッシュが利用されていることが記録されています。

2025-06-12 17:14:47.297: psql pid 2621: LOG: DB node id: 0 backend pid: 2901 statement: /*FORCE QUERY CACHE*/SELECT now(); 
2025-06-12 17:14:50.138: psql pid 2621: LOG: fetch from memory cache 
2025-06-12 17:14:50.138: psql pid 2621: DETAIL: query result fetched from cache. statement: /*FORCE QUERY CACHE*/SELECT now();

また /*NO QUERY CACHE*/ を冒頭に付記して宣言しても、 宣言したクエリキャッシュを削除することは出来ません。 /*NO QUERY CACHE*/ はキャッシュエントリが作成されないようにするだけなためです。

Pgpool-II を再起動することなく作成したクエリを削除する場合は、後述する PGPOOL SET CACHE DELETE コマンドか、pcp_invalidate_query_cache コマンドを使用する必要があります。

新しい PGPOOL SET CACHE DELETE コマンド

登録されているクエリキャッシュを削除する PGPOOL SET CACHE DELETE コマンドが追加されました。引数としてクエリの文字列を渡すことによってクエリキャッシュを指定して削除することができます。

postgres=> /*FORCE QUERY CACHE*/SELECT now();
              now
-------------------------------
 2025-06-12 09:58:49.983346+09
(1 行)

postgres=> PGPOOL SET CACHE DELETE '/*FORCE QUERY CACHE*/SELECT now();';
NOTICE:  query cache deleted. query: "/*FORCE QUERY CACHE*/SELECT now();"
SET
postgres=> /*FORCE QUERY CACHE*/SELECT now();
              now
-------------------------------
 2025-06-12 09:59:32.998492+09
(1 行)

引数に記述するクエリキャッシュはクエリ文字列は、末尾の「;」も含めて以前のクエリと完全に一致していなければならず、一致しない場合は以下エラーとなります。

postgres=> PGPOOL SET CACHE DELETE '/*FORCE QUERY CACHE*/SELECT now()'; -- 末尾の ';' が不足
NOTICE: query cache does not exist for query: "/*FORCE QUERY CACHE*/SELECT now()" -- クエリキャッシュが存在しないエラーとなる
SET

クエリキャッシュを削除する新しい PCP コマンド

すべてのクエリキャッシュを削除する PCP コマンド、pcp_invalidate_query_cache が追加されました。

今までは、クエリキャッシュの削除は Pgpool-II の再起動が必要でしたが、このコマンドを実行することによって Pgpool-II を再起動することなくクエリキャッシュを削除することができます。

「/*FORCE QUERY CACHE*/」で 「SELECT now();」 クエリをキャッシュします。

postgres=> /*FORCE QUERY CACHE*/SELECT now();
now
-------------------------------
2025-06-09 13:50:37.066191+09
(1 行)

その後、 pcp_invalidate_query_cache を実行すると、クエリキャッシュを削除することができます。

[postgres@server1 ~]$ pcp_invalidate_query_cache -h 192.168.100.50 -p 9898 -U pgpool -W
Password:
pcp_invalidate_query_cache -- Command Successful

postgres=> /*FORCE QUERY CACHE*/SELECT now(); -- クエリキャッシュが削除されているため再作成となる
now
-------------------------------
2025-06-09 13:50:56.561619+09
(1 行)

新しい設定パラメータ log_backend_messages

バックエンドからのメッセージログを出力する log_backend_messages パラメータが追加されました。terse または verbose に設定されている場合、バックエンドからのメッセージをログ出力します。

以下が受け取るメッセージ例です。

2025-06-09 14:00:57.494: psql pid 7579: LOG: last ParameterStatus message from backend 0 repeated 13 times

terse では、同じ種類のメッセージが同じバックエンドから送られてくると、その回数を記録し、次に異なる種類のメッセージが送られてきた時に繰り返し回数を報告します。そのため、繰り返している最中にセッションに対応するプロセスが強制終了すると、その分のログが出力されません。この場合でもすべてのログを出力するには、 verbose オプションを使用します。

verbose に設定したときのログ出力例は以下です。同一内容のメッセージであっても送られてくるたびに出力するためプロセスの強制終了によるログの損失は避けられますが、大量のメッセージがバックエンドから送られてくる場合は注意が必要です。

2025-06-09 13:58:16.390: child pid 7263: LOG: ParameterStatus message from backend 0
2025-06-09 13:58:16.390: child pid 7263: LOG: ParameterStatus message from backend 0
2025-06-09 13:58:16.390: child pid 7263: LOG: ParameterStatus message from backend 0

PostgreSQL 17 の SQL パーサの導入

Pgpool-II ではメジャーリリースするたびに、PostgreSQL の最新パーサを移植しています。今回のリリースでは PostgreSQL 17 の新しいパーサを取り込みました。

Pgpool-II の負荷分散機能では、SQL を解析して参照か更新かを判別し、どのノードに振り分けるかを決めています。そのため、PostgreSQL の新バージョンでの SQL の変更に対応するには、SQL パーサを移植する必要があります。

PostgreSQL 17 での SQL のおもな変更点は以下のとおりです。

• MERGE への NOT MATCHED BY SOURCE と RETURNING 句の追加
• COPY オプションの ON_ERROR ignore と LOG_VERBOSITY の追加
• COPY FROM オプションの FORCE_NOT_NULLとFORCE_NULL で「*」 を使用した全列を指定できる機能の追加
• EXPLAIN への SERIALIZE と MEMORY オプションの追加
• ALTER TABLE で SET STATISTICS DEFAULT を用いて、デフォルトの統計上情報ターゲットとする列の指定できる機能の追加
• ALTER TABLE での列の生成式を変更する機能の追加
• ALTER TABLE で .. SET ACCESS METHOD のデフォルトを指定できる機能の追加
• イベントトリガでログインイベントと REINDEX  を扱う機能の追加

Pgpool-II 4.6 では上記の変更点に対応しています。

Watchdog の hostname と heartbeat_hostname パラメータの IPv6 対応

これまで、IPv6 に対応していたパラメータは以下の通りです。

• backend_hostnameX
• listen_addresses
• pcp_listen_addresses

一方で、以下の Watchdog 関連パラメータはこれまで IPv6 に対応していませんでした。

• hostname
• heartbeat_hostname

今回のリリースにより、hostname と heartbeat_hostname も IPv6 に対応し、すべてのネットワーク関連パラメータで IPv6 アドレスを利用できるようになりました。

おわりに

今回は、Pgpool-II 4.6 の新機能について紹介しました。

Pgpool-II 4.6 では、より実用的で便利な機能が数多く追加・改善されています。PostgreSQL の高可用性構成や負荷分散の実現を検討されている方にとって、Pgpool-II は有力な選択肢です。ぜひこの機会に Pgpool-II の導入をご検討ください。

Watchdogとは

具体的にPgpool-II 4.1のwatchdogの機能強化について説明する前に、watchdogとは何かについておさらいしておきましょう。Watchdogは、Pgpool-IIのオプション機能の一つで、Pgpool-II自体の可用性を高めるものです。Pgpool-IIでは、以下の図のようにすべてのクライアントからのアクセスがPgpool-IIを経由してPostgreSQLに送られるので、もしもPgpool-IIがダウンしてしまうと、データベースがまったく使えなくなってしまいます。

そこでPgpool-IIを複数台用意し、万が一Pgpool-IIがダウンしてしまった時にもう1台のPgpool-IIに切り替えて処理を続行するのがwatchdogの役割です。

Pgpool-IIが切り替わっても、クライアントは引き続き同じVIP (Virtual IP)でPgpool-IIに接続することにより、Pgpool-IIが切り替わったことを意識せずにデータベースシステム全体の利用を継続することができます。この図ではPgpool-IIは2つですが、実際にはいくつでもPgpool-IIをもっと設置することも可能で、Pgpool-IIは3台以上の奇数台数を設置することが推奨されています。この理由については後で説明します。

なお、wathdog機能は実際にはPgpool-IIから起動される別プロセスで実装されていますが、概念的にはPgpool-II = watchdogと考えて差し支えありません。そこで、以下の説明ではPgpool-IIの代わりにwatchdogという用語を用います。

Watchdogの改善点その1 – マスタwatchdogノードの自動辞退

上の図で、VIPを持つwatchdogとVIPを持たないwatchdogの2つが出てきました。VIPを持つwatchdogは「マスタwatchodg」と呼ばれ、watchdogがいくつあっても、クラスタ内には1台のみ存在するのが原則です。マスタwatchdogはクラスタシステム起動時にパラメータ「wd_priority」パラメータが大きいwatchdogがその役割を担います。マスタ以外のwatchdogは「スタンバイ」と呼ばれます。

さて、昨今ではPostgreSQLはストリーミングレプリケーションで構成するのが一般的です。これにより、可用性や参照負荷分散などのメリットをユーザは享受できます。以下はPgpool-IIコミュニティによって推奨される本格的なクラスタシステムで、Pgpool-IIが3台、PostgreSQLが2台で構成されています。

（具体的なセットアップ方法はマニュアルに詳しく記載されています）

この図の中で点線が各Pgpool-IIからPostgreSQLに出ていますが、これは「ヘルスチェック」という、Pgpool-IIがPostgreSQLデータベースの健全性をチェックする機能を表しています。これにより、たとえばプライマリPostgreSQLがダウンしても、スタンバイPostgreSQLを自動昇格させてデータベースシステムとしての運用を継続することができます。

Pgpool-II同士で意見が合わない？

PostgreSQLの健全性の確認は、ネットワークを通じてPgpool-IIがPostgreSQLに接続することにより行われます。ネットワークが正常ならば、どのPgpool-IIから見てもPostgreSQLが正常かどうかの見解は変わらないはずです。しかし、今マスタPgpool-IIとプライマリPostgreSQLの間のネットワークだけに故障が発生したらどうでしょう？この場合、マスタPgpool-IIはプライマリPostgreSQLを故障と判断、スタンバイPgpool-IIは健全と判断し、意見が別れてしまいます。そこでwatchdogはお互いに意見を交換して多数決で判断を下し、マスタPgpool-IIの「故障」判断は却下されます。（Pgpool-IIが偶数だと多数決が下せないので、困ったことになります。これが奇数台のPgpool-IIを設置することが推奨される理由です)

判断が却下されたプライマリPgpool-IIはプライマリPostgreSQLを「隔離(quarantine)」状態にします。隔離状態にあるPostgreSQLにはPgpool-IIは問い合わせを送信せず、スタンバイPostgreSQLに問い合わせを送ることになります。しかし相変わらずVIPはそのマスタPgpool-IIにアサインされており、クライアントからの更新問い合わせもスタンバイに送られます。スタンバイのPostgreSQLでは更新処理が実行できないので、そうした問い合わせはすべてエラーになってしまします。

watchdogマスタが自主降格して問題を回避

そこでPgpool-II 4.1では、こうした場合にマスタwatchdogは自主的に自分を降格して他のPgpool-IIにマスタの役割を移譲するようになりました。もちろんVIPも新しいPgpool-IIにアサインされるので、引き続き更新処理も正常に実行することができます。

多数決原則はPgpool-IIダウン時にも適用

ちなみに、Pgpool-IIが多数決でものごとを決める仕組みは、Pgpool-II自体のダウン時にも適用されます。Pgpool-IIはお互いに通信しながら互いの生死を確認しており、たとえば以下の図のように、Pgpool-IIの1,2はお互いに通信できるが、3は他のPgpool-IIと通信できない状態になっても、Pgpool-II 3は過半数の投票を得られないため、勝手にPgpool-II 3がマスタに昇格してしまうことを防ぐことができます。これはいわゆる「スプリットブレイン」状態の防止につながります。

Watchdogの改善点その2 – 新しいパラメータenable_consensus_with_half_votes

前述のように、Pgpool-IIでは多数決でものごとを決められるように、設置台数を奇数台にすることが推奨されています。しかし世の中にはリソースを節約するために2台でシステムを更正している例も多く、従来はPgpool-II台数が偶数の場合にはその半分、すなわち1台だけの賛成が得られても多数決の合意が得られるとしていました。しかしこれでは、たとえば台数が4台の時に2台の賛成で合意が得られることになり、おかしなことになります。そこでPgpool-II 4.1では、デフォルトで過半数の合意を得るためにPgpool-II台数の過半数の賛成が必要となりました。しかしPgpool-II台数が2台のときには、これだとPgpool-IIが1台ダウンした時に決して過半数が得られなくなってしまうため、救済のために新しいパラメータenable_consensus_with_half_votesが追加されました。このパラメータがonなら、Pgpool-II台数が2台のときには、1台のPgpool-IIの賛成のみで合意が得られます。ただし、Pgpool-IIが2台構成の時は、お互いの監視ネットワークがダウンした時にお互いに自分だけが生きていると思い込むスプリットブレイン状態になることを防ぐことができない点は変わりません。

終わりに

9回に渡ってPgpool-II 4.1の新機能をご紹介しました。Pgpool-IIはバージョンごとに機能が充実しており、適用できる案件が増えてきていると思います。今回のリリースでは、すぐに利用できるインストール方法とともに、各種雛形設定ファイルも配布物に同梱されています。この機会にPgpool-IIを使ったPostgreSQLクラスタシステムの構築にチャレンジしてみてはいかがでしょう。

Pgpool-II 4.1の紹介【第1回】
Pgpool-II 4.1 新機能: ステートメントレベルの負荷分散【第2回】
Pgpool-II 4.1 新機能: reserved_connections【第3回】
Pgpool-II 4.1 新機能:自動フェイルバック 【第4回】
Pgpool-II 4.1 新機能:PostgreSQL 12への対応【第5回】
Pgpool-II 4.1 新機能:2拠点に分かれたレプリケーション構成への対応【第6回】
Pgpool-II 4.1 新機能: シェアードリレーションキャッシュ【第7回】
Pgpool-II 4.1 新機能: Pgpool-II によって発行される内部クエリの改善【第8回】
Pgpool-II 4.1 新機能: Watchdogの機能強化【第9回】

バージョン情報を活用した内部クエリの削減

Pgpool-IIは、クライアントから受信した問い合わせを解析するために必要な様々な情報を入手するためにPostgreSQLに内部的にクエリを発行します。第7回で解説したシェアードリレーションキャッシュは、そうしたクエリ結果のキャッシュの利用を改善するものでした。Pgpool-II 4.1では、それとは別に発行する内部クエリそのものを削減する努力をしています。その一つが、PostgreSQLのバージョン情報を活用した内部クエリの削減です。

バージョンで異なるPostgreSQLのシステムカタログへの問い合わせ

Pgpool-IIが発行する内部クエリは、主にPostgreSQLのシステムカタログを問い合わせるものです。たとえば、Pgpool-IIではあるテーブルが一時テーブルかどうか各テーブルごとに問い合わせを行います。一時テーブルを含む問い合わせはストリーミングレプリケーションのスタンバイサーバには送信できないからです。あるテーブルが一時テーブルかどうかの判断方法はPostgreSQLのバージョンで異なり、実は結構厄介です。

• PostgreSQL 8.4と9.0では、システムカタログpg_classの”relistemp”列がtrueなら一時テーブル
• それ以外のバージョンではスキーマが”pg_temp”なら一時テーブル

という具合です。従来は、

1. pg_classにrelistempという列があるかどうか調べる
2. もしなければシステムカタログpg_namespaceを調べてスキーマがpg_tempであるかどうか調べる
3. もしrelistempがあればそれがtrueなのかfalseなのか調べる

という具合に最大2回の内部クエリ発行が必要でした。

バージョン情報を活用して内部クエリを削減

Pgpool-II 4.1では、あらかじめPostgreSQLのバージョンを調べておき、それによってpg_classのrelistempを調べるか、pg_namespaceを調べるかを判断できるので、内部クエリの発行回数を1回にすることができます。

他の内部クエリでも同様の工夫を行うことにより、従来一つのユーザからの問い合わせにつき最大内部クエリが7回ほど発行されていたのが2-3回に減らすことができました。

より効率的な一時テーブルのチェック

上の改良により、一時テーブルのチェックはかなり効率的になりましたが、それでも一時テーブルかどうか知るための内部クエリを完全になくすことはできません。そこで導入されたのがcheck_temp_tableというパラメータです。このパラメータを"trace"に設定すると、システムカタログに内部クエリを発行せずに、CREATE TEMP TABLE文がこのセッションで投入されたかどうかを追跡することによって一時テーブルかどうかの判定を行います。これにより内部クエリの発行が不要になりますが、注意することもあります。

一時テーブルの生成がPgpool-IIから見えない場合（たとえば関数やトリガの中で行われる場合）、Pgpool-IIは一時テーブルの生成を認識できません。この場合は、check_temp_tableに”catalog”を設定することにより、従来と同じシステムカタログを検索する動作になります。

終わりに

今回はPgpool-IIが発行する内部クエリの改善について解説しました。Pgpool-IIの発行する内部クエリの多さが気になる方はPgpool-II 4.1を試してみてはいかがでしょう。

リレーションキャッシュ

Pgpool-IIではクライアントから送られてきたクエリを解析し、クエリに含まれているテーブルや関数に関する情報をバックエンドのPostgreSQL上のシステムカタログから取得しています。
これらの取得した情報により柔軟なクエリレベルの負荷分散などの様々な機能が実現しています。
クエリが実行されるたびにシステムカタログを参照しに行くと無視できないオーバヘッドとなるため、各子プロセスでは1度取得した情報はローカルメモリにキャッシュしておきます。これをリレーションキャッシュと呼びます。
ローカルメモリに既に該当のシステムカタログ情報がキャッシュされている場合、それを直接使用することでこのオーバヘッドを軽減しています。

シェアードリレーションキャッシュ

Pgpool-IIの起動直後やPostgreSQLのフェイルオーバ処理後、その他各種設定により子プロセスが再起動した直後では子プロセスはローカルキャッシュを持っていません。そのため num_init_children が大きな値に設定されるような接続数が多いシステムの場合、子プロセスの数だけシステムカタログへの問い合わせが同時に発生し、このオーバヘッドが重なり大きくなる場合があります。

このような場合を想定して、Pgpool-II 4.1ではリレーションキャッシュをローカルキャッシュに加えて共有メモリにもキャッシュできる機能が追加されました。この機能は、デフォルトで有効(enable_shared_relcache=on)となります。
リレーションキャッシュはローカルキャッシュに加え、 memqcache_method(デフォルトは’shmem’) で指定されているキャッシュストレージに保存されます。
各子プロセスは、自身のローカルキャッシュにシステムカタログの情報が無ければ、キャッシュストレージを確認し、どちらにもなかった場合のみ、PostgreSQLのシステムカタログを参照します。その後、システムカタログから取得した情報は、自身のローカルキャッシュとキャッシュストレージの双方にキャッシュします。
つまり、いずれかの子プロセスが参照したシステムカタログはすべての子プロセスで共有されるため、上記のようなケースでも同じシステムカタログを参照する処理は1度で済むため、オーバヘッドをかなり抑えることができます。

ベンチマークによるシェアードリレーションキャッシュ機能の効果

PostgreSQL12とPgpool-II 4.1を用いた簡易なベンチマークテストを行いました。以下のグラフは、 enable_shared_relation_cache=off の場合と比較して enable_shared_relation_cache=on の場合に実行速度が相対的にどの程度向上しているかを表しています。この結果より、シェアードリレーションキャッシュ機能により2倍程度実行速度が向上していることが確認できました。

(テストコマンド)
pgbench  -C -T 30 -c 30 -n -f script_file

まとめ

今回は、Pgpool-II 4.1で追加されたシェアードリレーションキャッシュ機能について紹介しました。
この機能によりPgpool-II自体のオーバヘッドを軽減し、より快適に使用することができます。
特に num_init_children の設定値が大きい場合や、接続先のテーブル数が多い大規模な環境で効果が見込めるため、このような環境の場合Pgpool-II 4.1の使用を検討していただくと良いかと思います。

PostgreSQL 12 への対応として、おもに最新の SQL パーサの移植とフェイルオーバやリカバリで使うサンプルスクリプトの修正が行われました。

PostgreSQL 12 SQL パーサの移植

Pgpool-II の負荷分散機能では、SQL を解析して参照か更新かを判別し、どのノードに振り分けるかを決めています。そのため、PostgreSQL の新バージョンでの SQL の変更に対応するには、SQL パーサを移植する必要があります。

PostgreSQL 12 での SQL のおもな変更点は以下のとおりです。

• VACUUM コマンドの SKIP_LOCKED、INDEX_CLEANUP、TRUNCATE オプション
• COMMIT AND CHAIN と ROLLBACK AND CHAIN コマンド
• COPY FROM コマンドの WHERE 句
• CREATE OR REPLACE AGGREGATE コマンド
• CREATE STATISTICS コマンドの mcv 種別
• REINDEX コマンドの CONCURRENTLY オプション
• EXPLAIN コマンドの SETTINGS オプション

Pgpool-II 4.1 では上記の変更点に対応しています。

サンプルスクリプトの修正

PostgreSQL 12 では、ストリーミングレプリケーションでスタンバイとして起動する場合の設定ファイル recovery.conf が廃止されました。パラメータは設定ファイル postgresql.conf で設定するように統合されました。また、スタンバイとして起動するかは recovery.signal ファイルを配置して指定するようになりました。

それに伴って、フェイルオーバやリカバリで使うサンプルスクリプトが修正され、PostgreSQL 12 でも動作するようになりました。サンプルスクリプトは Pgpool-II 4.1 文書 の「8.3. Pgpool-II + Watchdog の構築の例」に掲載されています。

また、今回のリリースからサンプルスクリプトが配布物に同梱されるようになりました。RPM パッケージを使ってインストールした場合には、/etc/pgpool-II ディレクトリに配置されます。

$ ll /etc/pgpool-II/*.sample
-rwxr-xr-x 1 postgres postgres 2756 11月 19 09:06 /etc/pgpool-II/failover.sh.sample
-rwxr-xr-x 1 postgres postgres 6575 11月 19 09:06 /etc/pgpool-II/follow_master.sh.sample
-rwxr-xr-x 1 postgres postgres 1080 11月 19 09:06 /etc/pgpool-II/pgpool_remote_start.sample
-rwxr-xr-x 1 postgres postgres 2830 11月 19 09:06 /etc/pgpool-II/recovery_1st_stage.sample
-rwxr-xr-x 1 postgres postgres 712 11月 19 09:06 /etc/pgpool-II/recovery_2nd_stage.sample

サンプルスクリプトを使う場合には、ファイル名から .sample を外して適当な場所にコピーし、変数 PGHOME を PostgreSQL のインストール先に合わせて変更してください。

また、pgpool_setup が生成するスクリプトも PostgreSQL 12 に対応しています。

まとめ

今回、PostgreSQL 12 への対応として SQL パーサの移植とサンプルスクリプトの修正について説明しました。今回からサンプルスクリプトが同梱されるようになったことで、これまでスクリプトの作成に悩んでいた方も導入しやすくなったと思います。これを機に Pgpool-II の導入をぜひお試しください。