A.4. リリース 4.1.16

マルチステートメントのクエリを判定するために、psqlscanのソースコードをPgpool-IIにインポートしました。(Tatsuo Ishii)

psqlscanは、PostgreSQLソースツリー内のモジュールです。 これは本質的にPostgreSQL SQLスキャナのサブセットですが、各SQLステートメントの終わりの検出に特化しています。 したがって、これを使用してクエリ文字列内のSQLステートメントの数をカウントできます。

議論: https://www.pgpool.net/pipermail/pgpool-hackers/2023-February/04291.html 議論: https://www.pgpool.net/pipermail/pgpool-hackers/2023-April/004320.html

複数のステートメントを幅広く使用できるようにしました。 (Tatsuo Ishii)

このコミットは、複数のステートメント (マルチステートメント) に関するPgpool-IIの長年の制限を排除しました。

議論: https://www.pgpool.net/pipermail/pgpool-hackers/2023-February/004287.html

内部クエリでスキーマ修飾を使用するように変更しました。(Tatsuo Ishii)

関数やキャストなどの一部のオブジェクトは、「pg_catalog.」スキーマ修飾を使用していませんでした。 これによって直ちにセキュリティ上の懸念が生じるわけではありませんが、スキーマ修飾を使用することは常に良い習慣ですので、変更しました。

共有リレーションキャッシュで発生しうるデッドロックを修正しました。(Tatsuo Ishii)

ユーザー定義関数がテーブルロックを取得する場合、拡張クエリプロトコルを使用して関数を呼び出すとデッドロックが発生する可能性がありました。 以下にシナリオを示します。

• (1) セッション中クライアントはparse、bind、executeリクエストをpgpoolに送信します。

• (2) セッションAのPgpool-IIはリクエストをPostgreSQLに転送します。

• (3) セッションAのPostgreSQLがexecuteを実行し、テーブルロックが発生します。

• (4) セッションBで、クライアントは関数のparse、bind、executeリクエストをpgpoolに送信します。

• (5) セッションBのPgpoolはリクエストをPostgreSQLに転送します。

• (6) セッションBのPostgreSQLはbindを実行しますが、テーブルはセッションAのPostgreSQLによってすでにロックされており、ロックの解放を待ちます。

• (7) セッションBのpgpoolはexecuteをPostgreSQLに転送した後、関数の揮発性をチェックするために共有リレーションキャッシュを検索するためのセマフォを取得します。 次に、do_queryを呼び出し、フラッシュメッセージをPostgreSQLに送信して、この時点までのPostgreSQLからの応答を取得します。 ただし、#6ではPostgreSQLがテーブルロックを待機しているため、pgpoolはバインド完了後のメッセージを待つ必要があります。

• (8) セッションAのpgpoolがPostgreSQLにexecuteを転送した後、関数の揮発性をチェックするために共有リレーションキャッシュを検索しセマフォを取得しようとしましたが、セマフォはセッションBのpgpoolによってすでに取得されているため、セマフォの解放を待ちます。

• (9) セッションAとセッションBがお互いを待機するため、デッドロックが発生します。

これを修正するには、do_query()を呼び出す前にセマフォを解放するようにpool_search_relcache()を変更しました(ただし、セマフォはdo_query()の後に取得します)。 これにより、上記#8のセッションAはセマフォを取得し、先に進むことができます。 クライアントからsyncメッセージを受信し、PostgreSQLに転送します。 syncを受信すると、ユーザ定義関数は実行を終了し、テーブルロックを解放します。 これにより、セッションBのPostgreSQLがテーブルロックを取得できるようになります。

musl libcを使用するシステムでのコンパイルエラーを修正しました。(bug 790) (Tatsuo Ishii)

パッチはleimaohuiによって提供されました。

複数のクエリキャッシュの不具合を修正しました。(Tatsuo Ishii)

議論: https://www.pgpool.net/pipermail/pgpool-hackers/2023-January/004259.html

特殊なケースでsrワーカーが間違ったクエリをスタンバイサーバに送信する不具合を修正しました。(Tatsuo Ishii)

ALWAYS_PRIMARYフラグが設定されている場合、PRIMARY_NODE_IDマクロは、プライマリがダウンしている場合でも、-1ではなくノードIDを返していました。 この場合、ストリーミングレプリケーション遅延をチェックするワーカープロセスは、PostgreSQLのバージョンに応じてSELECT pg_current_wal_lsn()またはSELECT pg_current_xlog_location()をスタンバイに送信し、当然エラーが発生していました。

議論: https://www.pgpool.net/pipermail/pgpool-hackers/2023-February/004279.html

DEALLOCATEによる種類不一致エラーを修正しました。 (bug 780) (Tatsuo Ishii)

以下の条件がすべて満たされた場合、種類不一致エラーが発生していました。

• ストリーミングレプリケーションモード

• ロードバランスノードがプライマリ以外のノード

• PREPAREがマルチステートメントクエリで使用されている

wd_priorityの説明を追加しました。(Chen Ningwei)

PREPARE/EXECUTE/DEALLOCATEに関する制限を追加しました。(Tatsuo Ishii)

Pgpool-IIで-Dオプションを使用する場合の注意点を追加しました。(Tatsuo Ishii)

「RPMからのインストール」セクションを強化しました。(Bo Peng)

「Pgpool-II + Watchdogの構築の例」から「-D」起動オプションの設定を削除しました。(Bo Peng)

AES256をサポートするには--with-opensslオプションが必要であることを記載しました。(Tatsuo Ishii)

.pcppassを使用するには、pcpコマンドの-wオプションが必要であることを記載しました。(Tatsuo Ishii)

SHOW POOL_CACHEを強化しました。(Tatsuo Ishii)

071.execute_and_deallocate/test.shをリファクタリングしました。(Tatsuo Ishii)

いくつかの回帰テストを強化しました。(Tatsuo Ishii)

時折発生する005.jdbcテストの失敗を修正しました。(Tatsuo Ishii)