Pgpool-II 4.2.19 文書 | |||
---|---|---|---|
前のページ | 上に戻る | 付録 A. リリースノート | 次のページ |
リリース日: 2023-08-17
共有メモリの初期化後にのみ、システム終了コールバックを呼び出すようにしました。(Muhammad Usama)
共有メモリの取得に失敗して、終了時コールバックが呼び出された場合、クリーンアップ関数は、共有メモリに存在するprocess_infoにアクセスする際にセグメンテーション違反を引き起こす可能性がありました。 process_infoがNULLのときに終了コールバックからの中断で修正することもできますが、共有メモリの初期化に成功した後に関数をインストールする方がより良いアプローチです。 なぜなら、システムの残りの部分は常にprocess_infoがNULLになることはないと想定しており、また、子プロセスが生成される前にクリーンアップをする必要はないからです。
一部のシステムカタログ照会関数にスキーマ修飾を追加しました。(Tatsuo Ishii)
Coverityの警告を修正しました。(Tatsuo Ishii)
クエリキャッシュのモジュールで、time_tの値がint32変数に割り当てられる問題を修正しました。 Coverityの指摘に従いまして、変数の型をint64に変更しました。 また、time_tの差分を計算するためにdifftime()を使用しました。これは推奨される方法です。 https://www.jpcert.or.jp/sc-rules/c-msc05-c.html
find_primary_node_repeatedlyがsearch_primary_node_timeout指定時間内で終了しない問題を修正しました。(Bo Peng)
v2プロトコルを利用する場合のクラッシュを修正しました。(bug 807)(Tatsuo Ishii)
read_kind_from_backend()で統計データを蓄積する際、v2プロトコルのケースには対応していませんでした。
MCanivezからバグ報告とパッチを提供いただきました。
マルチステートメントにおけるPREPAREの利用を修正しました。(Tatsuo Ishii)
マルチステートメントの二番目以降の位置にPREPAREが含まれている場合、その後のbindメッセージでプリペアドステートメントを利用すると、送信されたメッセージにプリペアドステートメントが保存されな いため、「unable to bind」エラーが発生していました。
この問題を修正するために、ステートメントを解析した後にそのようなケースが見つかった場合、名前付きステートメントのクエリコンテキストを作成し、送信メッセージのリストに追加するようにしました。
議論: https://www.pgpool.net/pipermail/pgpool-general/2023-July/008931.html
この修正のため、リグレッションテスト079..multi_prepareを追加しました。
pgprotoをパラメータを使用するbindメッセージを処理できるようにしました。(Tatsuo Ishii)
以前、pgprotoはパラメータを持たないbindメッセージしか処理できませんでした。
サンプルスクリプトのログメッセージを修正しました。(Bo Peng)
loggerプロセスのアプリケーション名記載漏れを修正しました。(Bo Peng)
停止モードの意味を明確にしました。(Tatsuo Ishii)
4.2.10リリースノートにあった誤った情報を削除しました。(Bo Peng)
「pgpool_recovery拡張のスクリプトを修正しました。 (Tatsuo Ishii)」の記載を削除しました。
「8.2. Pgpool-II + Watchdogの構築の例」のSSH公開鍵認証の説明を補足しました。(Bo Peng)
負荷分散章の説明を修正しました。(Tatsuo Ishii)
一部の文章で「ストリーミングレプリケーションモード」と記述されるべきの箇所が「ネイティブレプリケーションモード」となっていました。 また、ストリーミングレプリケーションモードにおける負荷分散の追加要件に関する説明を改善しました。 いくつかのインデックスを追加しました。
オンラインリカバリーの説明を改善しました。(Bo Peng)
複数のpgpoolノードでwatchdogが有効になっていない場合、オンラインリカバリーのセカンドステージが適切に機能しないことについて言及しました。
時折発生する069.memory_leak_extendedテストの失敗を修正しました。(Tatsuo Ishii)
偶発するテストの失敗の原因は、pgbenchが終了した後にpsコマンドを実行する前にpgpoolの子プロセスが消えてしまうことにあると判明しました。 これにより、「DISCARD ALL cannot be executed within a pipeline」というkind mismatchのFATALエラーが発生していました。 これを修正するために、pgbenchをバックグラウンドで実行し、pgbenchが終了する前にプロセスのサイズを取得するようにしました。
議論: https://www.pgpool.net/pipermail/pgpool-hackers/2023-May/004338.html