<!-- doc/src/sgml/release-4.1.sgml -->
<!-- See header comment in release.sgml about typical markup -->
+<sect1 id="release-4-1-22">
+ <title>リリース 4.1.22</title>
+ <note>
+ <title>リリース日</title>
+ <simpara>2024-09-09</simpara>
+ </note>
+
+ <sect2>
+ <title>概要</title>
+ <para>
+ このリリースには、セキュリティ修正が含まれています。
+ </para>
+ <para>
+ クエリキャッシュ機能（<xref linkend="runtime-in-memory-query-cache">）が有効な時に、データベースユーザがクエリキャッシュ経由で本来読み出せない行を読むことが可能でした。(CVE-2024-45624)
+ </para>
+ <para>
+ 4.5.4, 4.4.9, 4.3.12, 4.2.19, 4.1.22より古く、クエリキャッシュ機能を持つすべてのバージョン(クエリキャッシュ機能は3.2で実装されました)がこの脆弱性の影響を受けます。
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ あるユーザのクエリキャッシュがテーブルに対して作成されていると、そのテーブルへのアクセス権がREVOKEコマンドで剥奪されても、アクセス権を持たないそのユーザがクエリキャッシュを通じてテーブルにアクセスすることが可能でした。
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ ユーザAのクエリキャッシュがテーブルに対して作成されていて、同じセッション内でSET ROLEあるいはSET SESSION_AUTHORIZATIONで他のユーザBに切り替えてそのテーブルにアクセスすると、アクセス権を持たないBがクエリキャッシュを通じてアクセスすることが可能でした。
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ ユーザAのクエリキャッシュが行セキュリティが有効なテーブルに対して作成されていて、同じセッション内でSET ROLEあるいはSET SESSION_AUTHORIZATIONで他のユーザBに切り替えてそのテーブルにアクセスすると、本来Bが見えない行をクエリキャッシュを通じて取り出すことが可能でした。
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ Pgpool-II 4.5.4, 4.4.9, 4.3.12, 4.2.19, 4.1.22以降へのアップグレードを強くお勧めします。
+ それができない場合は、クエリキャッシュ機能を無効にしてください。
+ </para>
+ <para>
+ なお、この脆弱性を修正するために、いくつかのコマンド(ALTER DATABASE, ALTER ROLE, ALTER TABLE, REVOKE)を実行すると、クエリキャッシュのすべてのデータを削除するようになりました。
+ これにより、クエリキャッシュの性能に影響があるかも知れません。
+ </para>
+ </sect2>
+
+ <sect2>
+ <title>変更点</title>
+ <itemizedlist>
+ <listitem>
+ <!--
+ 2024-08-15 [c802c1e]
+ -->
+ <para>
+ <xref linkend="guc-notice-per-node-statement">をバックポートしました。 (Tatsuo Ishii)
+ </para>
+ <para>
+ これは主にテストのためです。v4.1までバックポートしました。
+ </para>
+ <para>
+ Discussion: <ulink url="https://www.pgpool.net/pipermail/pgpool-hackers/2024-August/004505.html">[pgpool-hackers: 4504]</ulink>
+ </para>
+ </listitem>
+ </itemizedlist>
+ </sect2>
+
+ <sect2>
+ <title>不具合修正</title>
+ <itemizedlist>
+
+ <listitem>
+ <!--
+ 2024-08-09 [e25f5d6]
+ 2024-08-11 [781859a]
+ -->
+ <para>
+ レプリケーションモードとスナップショットアイソレーションモードで発生する複数の不具合を修正しました。(Tatsuo Ishii)
+ </para>
+ <para>
+ 次の不具合を修正しました。
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ レプリケーションモードおよびスナップショットアイソレーションモードでコマンドを実行すると、<productname>Pgpool-II</productname>はクエリ準備完了メッセージを待ちますが、一部のコマンド（<command>SET ROLE</command>など）がパラメータステータスメッセージを生成することを忘れていました。
+ その結果、<productname>Pgpool-II</productname>はクエリ準備完了メッセージの前に他のメッセージが到着したことをエラーとして出力していました。
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 前のクエリがパラメータステータスメッセージを生成した場合、後続の<function>parse()</function>はそれを読み取って処理する必要があります。
+ これは、パラメータステータスメッセージの後に続くはずのクエリ準備完了メッセージを読み取る必要があるためです。
+ </para>
+ <para>
+ ただし、<function>ParameterStatus()</function>が呼び出されると、クエリ進行中フラグが設定され、この<function>parse()</function>呼び出しで処理されるクエリが負荷分散されている場合、バックエンドからのパラメータステータスメッセージの1つだけが処理される可能性がありました。
+ パラメータステータスメッセージは<command>SET</command>コマンドによって生成され、<command>SET</command>コマンドはレプリケーションモードおよびスナップショットアイソレーションモードのすべての生きているバックエンドに送信されるため、すべての生きているバックエンドから送信される可能性がありました。
+ そのため、ParameterStatus()を呼び出す前に、クエリ進行中フラグを設定解除するように修正しました。
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </listitem>
+ </itemizedlist>
+ </sect2>
+</sect1>
+
<sect1 id="release-4-1-21">
<title>リリース 4.1.21</title>
<note>
<!-- doc/src/sgml/release-4.2.sgml -->
<!-- See header comment in release.sgml about typical markup -->
+<sect1 id="release-4-2-19">
+ <title>リリース 4.2.19</title>
+ <note>
+ <title>リリース日</title>
+ <simpara>2024-09-09</simpara>
+ </note>
+
+ <sect2>
+ <title>概要</title>
+ <para>
+ このリリースには、セキュリティ修正が含まれています。
+ </para>
+ <para>
+ クエリキャッシュ機能（<xref linkend="runtime-in-memory-query-cache">）が有効な時に、データベースユーザがクエリキャッシュ経由で本来読み出せない行を読むことが可能でした。(CVE-2024-45624)
+ </para>
+ <para>
+ 4.5.4, 4.4.9, 4.3.12, 4.2.19, 4.1.22より古く、クエリキャッシュ機能を持つすべてのバージョン(クエリキャッシュ機能は3.2で実装されました)がこの脆弱性の影響を受けます。
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ あるユーザのクエリキャッシュがテーブルに対して作成されていると、そのテーブルへのアクセス権がREVOKEコマンドで剥奪されても、アクセス権を持たないそのユーザがクエリキャッシュを通じてテーブルにアクセスすることが可能でした。
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ ユーザAのクエリキャッシュがテーブルに対して作成されていて、同じセッション内でSET ROLEあるいはSET SESSION_AUTHORIZATIONで他のユーザBに切り替えてそのテーブルにアクセスすると、アクセス権を持たないBがクエリキャッシュを通じてアクセスすることが可能でした。
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ ユーザAのクエリキャッシュが行セキュリティが有効なテーブルに対して作成されていて、同じセッション内でSET ROLEあるいはSET SESSION_AUTHORIZATIONで他のユーザBに切り替えてそのテーブルにアクセスすると、本来Bが見えない行をクエリキャッシュを通じて取り出すことが可能でした。
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ Pgpool-II 4.5.4, 4.4.9, 4.3.12, 4.2.19, 4.1.22以降へのアップグレードを強くお勧めします。
+ それができない場合は、クエリキャッシュ機能を無効にしてください。
+ </para>
+ <para>
+ なお、この脆弱性を修正するために、いくつかのコマンド(ALTER DATABASE, ALTER ROLE, ALTER TABLE, REVOKE)を実行すると、クエリキャッシュのすべてのデータを削除するようになりました。
+ これにより、クエリキャッシュの性能に影響があるかも知れません。
+ </para>
+ </sect2>
+
+ <sect2>
+ <title>変更点</title>
+ <itemizedlist>
+ <listitem>
+ <!--
+ 2024-08-15 [e5f3056]
+ -->
+ <para>
+ <xref linkend="guc-notice-per-node-statement">をバックポートしました。 (Tatsuo Ishii)
+ </para>
+ <para>
+ これは主にテストのためです。v4.1までバックポートしました。
+ </para>
+ <para>
+ Discussion: <ulink url="https://www.pgpool.net/pipermail/pgpool-hackers/2024-August/004505.html">[pgpool-hackers: 4504]</ulink>
+ </para>
+ </listitem>
+ </itemizedlist>
+ </sect2>
+
+ <sect2>
+ <title>不具合修正</title>
+ <itemizedlist>
+
+ <listitem>
+ <!--
+ 2024-08-09 [7d97cdb]
+ 2024-08-11 [0c10733]
+ -->
+ <para>
+ レプリケーションモードとスナップショットアイソレーションモードで発生する複数の不具合を修正しました。(Tatsuo Ishii)
+ </para>
+ <para>
+ 次の不具合を修正しました。
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ レプリケーションモードおよびスナップショットアイソレーションモードでコマンドを実行すると、<productname>Pgpool-II</productname>はクエリ準備完了メッセージを待ちますが、一部のコマンド（<command>SET ROLE</command>など）がパラメータステータスメッセージを生成することを忘れていました。
+ その結果、<productname>Pgpool-II</productname>はクエリ準備完了メッセージの前に他のメッセージが到着したことをエラーとして出力していました。
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 前のクエリがパラメータステータスメッセージを生成した場合、後続の<function>parse()</function>はそれを読み取って処理する必要があります。
+ これは、パラメータステータスメッセージの後に続くはずのクエリ準備完了メッセージを読み取る必要があるためです。
+ </para>
+ <para>
+ ただし、<function>ParameterStatus()</function>が呼び出されると、クエリ進行中フラグが設定され、この<function>parse()</function>呼び出しで処理されるクエリが負荷分散されている場合、バックエンドからのパラメータステータスメッセージの1つだけが処理される可能性がありました。
+ パラメータステータスメッセージは<command>SET</command>コマンドによって生成され、<command>SET</command>コマンドはレプリケーションモードおよびスナップショットアイソレーションモードのすべての生きているバックエンドに送信されるため、すべての生きているバックエンドから送信される可能性がありました。
+ そのため、ParameterStatus()を呼び出す前に、クエリ進行中フラグを設定解除するように修正しました。
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </listitem>
+ </itemizedlist>
+ </sect2>
+</sect1>
+
<sect1 id="release-4-2-18">
<title>リリース 4.2.18</title>
<note>
<!-- doc/src/sgml/release-4.3.sgml -->
<!-- See header comment in release.sgml about typical markup -->
+<sect1 id="release-4-3-12">
+ <title>リリース 4.3.12</title>
+ <note>
+ <title>リリース日</title>
+ <simpara>2024-09-09</simpara>
+ </note>
+
+ <sect2>
+ <title>概要</title>
+ <para>
+ このリリースには、セキュリティ修正が含まれています。
+ </para>
+ <para>
+ クエリキャッシュ機能（<xref linkend="runtime-in-memory-query-cache">）が有効な時に、データベースユーザがクエリキャッシュ経由で本来読み出せない行を読むことが可能でした。(CVE-2024-45624)
+ </para>
+ <para>
+ 4.5.4, 4.4.9, 4.3.12, 4.2.19, 4.1.22より古く、クエリキャッシュ機能を持つすべてのバージョン(クエリキャッシュ機能は3.2で実装されました)がこの脆弱性の影響を受けます。
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ あるユーザのクエリキャッシュがテーブルに対して作成されていると、そのテーブルへのアクセス権がREVOKEコマンドで剥奪されても、アクセス権を持たないそのユーザがクエリキャッシュを通じてテーブルにアクセスすることが可能でした。
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ ユーザAのクエリキャッシュがテーブルに対して作成されていて、同じセッション内でSET ROLEあるいはSET SESSION_AUTHORIZATIONで他のユーザBに切り替えてそのテーブルにアクセスすると、アクセス権を持たないBがクエリキャッシュを通じてアクセスすることが可能でした。
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ ユーザAのクエリキャッシュが行セキュリティが有効なテーブルに対して作成されていて、同じセッション内でSET ROLEあるいはSET SESSION_AUTHORIZATIONで他のユーザBに切り替えてそのテーブルにアクセスすると、本来Bが見えない行をクエリキャッシュを通じて取り出すことが可能でした。
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ Pgpool-II 4.5.4, 4.4.9, 4.3.12, 4.2.19, 4.1.22以降へのアップグレードを強くお勧めします。
+ それができない場合は、クエリキャッシュ機能を無効にしてください。
+ </para>
+ <para>
+ なお、この脆弱性を修正するために、いくつかのコマンド(ALTER DATABASE, ALTER ROLE, ALTER TABLE, REVOKE)を実行すると、クエリキャッシュのすべてのデータを削除するようになりました。
+ これにより、クエリキャッシュの性能に影響があるかも知れません。
+ </para>
+ </sect2>
+
+ <sect2>
+ <title>変更点</title>
+ <itemizedlist>
+ <listitem>
+ <!--
+ 2024-08-15 [907d91c]
+ -->
+ <para>
+ <xref linkend="guc-notice-per-node-statement">をバックポートしました。 (Tatsuo Ishii)
+ </para>
+ <para>
+ これは主にテストのためです。v4.1までバックポートしました。
+ </para>
+ <para>
+ Discussion: <ulink url="https://www.pgpool.net/pipermail/pgpool-hackers/2024-August/004505.html">[pgpool-hackers: 4504]</ulink>
+ </para>
+ </listitem>
+ </itemizedlist>
+ </sect2>
+
+ <sect2>
+ <title>不具合修正</title>
+ <itemizedlist>
+
+ <listitem>
+ <!--
+ 2024-08-09 [01c7229]
+ 2024-08-11 [fbecbd9]
+ -->
+ <para>
+ レプリケーションモードとスナップショットアイソレーションモードで発生する複数の不具合を修正しました。(Tatsuo Ishii)
+ </para>
+ <para>
+ 次の不具合を修正しました。
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ レプリケーションモードおよびスナップショットアイソレーションモードでコマンドを実行すると、<productname>Pgpool-II</productname>はクエリ準備完了メッセージを待ちますが、一部のコマンド（<command>SET ROLE</command>など）がパラメータステータスメッセージを生成することを忘れていました。
+ その結果、<productname>Pgpool-II</productname>はクエリ準備完了メッセージの前に他のメッセージが到着したことをエラーとして出力していました。
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 前のクエリがパラメータステータスメッセージを生成した場合、後続の<function>parse()</function>はそれを読み取って処理する必要があります。
+ これは、パラメータステータスメッセージの後に続くはずのクエリ準備完了メッセージを読み取る必要があるためです。
+ </para>
+ <para>
+ ただし、<function>ParameterStatus()</function>が呼び出されると、クエリ進行中フラグが設定され、この<function>parse()</function>呼び出しで処理されるクエリが負荷分散されている場合、バックエンドからのパラメータステータスメッセージの1つだけが処理される可能性がありました。
+ パラメータステータスメッセージは<command>SET</command>コマンドによって生成され、<command>SET</command>コマンドはレプリケーションモードおよびスナップショットアイソレーションモードのすべての生きているバックエンドに送信されるため、すべての生きているバックエンドから送信される可能性がありました。
+ そのため、ParameterStatus()を呼び出す前に、クエリ進行中フラグを設定解除するように修正しました。
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </listitem>
+ </itemizedlist>
+ </sect2>
+</sect1>
+
<sect1 id="release-4-3-11">
<title>リリース 4.3.11</title>
<note>
<!-- doc/src/sgml/release-4.4.sgml -->
<!-- See header comment in release.sgml about typical markup -->
+<sect1 id="release-4-4-9">
+ <title>リリース 4.4.9</title>
+ <note>
+ <title>リリース日</title>
+ <simpara>2024-09-09</simpara>
+ </note>
+
+ <sect2>
+ <title>概要</title>
+ <para>
+ このリリースには、セキュリティ修正が含まれています。
+ </para>
+ <para>
+ クエリキャッシュ機能（<xref linkend="runtime-in-memory-query-cache">）が有効な時に、データベースユーザがクエリキャッシュ経由で本来読み出せない行を読むことが可能でした。(CVE-2024-45624)
+ </para>
+ <para>
+ 4.5.4, 4.4.9, 4.3.12, 4.2.19, 4.1.22より古く、クエリキャッシュ機能を持つすべてのバージョン(クエリキャッシュ機能は3.2で実装されました)がこの脆弱性の影響を受けます。
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ あるユーザのクエリキャッシュがテーブルに対して作成されていると、そのテーブルへのアクセス権がREVOKEコマンドで剥奪されても、アクセス権を持たないそのユーザがクエリキャッシュを通じてテーブルにアクセスすることが可能でした。
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ ユーザAのクエリキャッシュがテーブルに対して作成されていて、同じセッション内でSET ROLEあるいはSET SESSION_AUTHORIZATIONで他のユーザBに切り替えてそのテーブルにアクセスすると、アクセス権を持たないBがクエリキャッシュを通じてアクセスすることが可能でした。
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ ユーザAのクエリキャッシュが行セキュリティが有効なテーブルに対して作成されていて、同じセッション内でSET ROLEあるいはSET SESSION_AUTHORIZATIONで他のユーザBに切り替えてそのテーブルにアクセスすると、本来Bが見えない行をクエリキャッシュを通じて取り出すことが可能でした。
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ Pgpool-II 4.5.4, 4.4.9, 4.3.12, 4.2.19, 4.1.22以降へのアップグレードを強くお勧めします。
+ それができない場合は、クエリキャッシュ機能を無効にしてください。
+ </para>
+ <para>
+ なお、この脆弱性を修正するために、いくつかのコマンド(ALTER DATABASE, ALTER ROLE, ALTER TABLE, REVOKE)を実行すると、クエリキャッシュのすべてのデータを削除するようになりました。
+ これにより、クエリキャッシュの性能に影響があるかも知れません。
+ </para>
+ </sect2>
+
+ <sect2>
+ <title>変更点</title>
+ <itemizedlist>
+ <listitem>
+ <!--
+ 2024-08-15 [730acde]
+ -->
+ <para>
+ <xref linkend="guc-notice-per-node-statement">をバックポートしました。 (Tatsuo Ishii)
+ </para>
+ <para>
+ これは主にテストのためです。v4.1までバックポートしました。
+ </para>
+ <para>
+ Discussion: <ulink url="https://www.pgpool.net/pipermail/pgpool-hackers/2024-August/004505.html">[pgpool-hackers: 4504]</ulink>
+ </para>
+ </listitem>
+ </itemizedlist>
+ </sect2>
+
+ <sect2>
+ <title>不具合修正</title>
+ <itemizedlist>
+
+ <listitem>
+ <!--
+ 2024-08-09 [1f200d7]
+ 2024-08-11 [ce7ed50]
+ -->
+ <para>
+ レプリケーションモードとスナップショットアイソレーションモードで発生する複数の不具合を修正しました。(Tatsuo Ishii)
+ </para>
+ <para>
+ 次の不具合を修正しました。
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ レプリケーションモードおよびスナップショットアイソレーションモードでコマンドを実行すると、<productname>Pgpool-II</productname>はクエリ準備完了メッセージを待ちますが、一部のコマンド（<command>SET ROLE</command>など）がパラメータステータスメッセージを生成することを忘れていました。
+ その結果、<productname>Pgpool-II</productname>はクエリ準備完了メッセージの前に他のメッセージが到着したことをエラーとして出力していました。
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 前のクエリがパラメータステータスメッセージを生成した場合、後続の<function>parse()</function>はそれを読み取って処理する必要があります。
+ これは、パラメータステータスメッセージの後に続くはずのクエリ準備完了メッセージを読み取る必要があるためです。
+ </para>
+ <para>
+ ただし、<function>ParameterStatus()</function>が呼び出されると、クエリ進行中フラグが設定され、この<function>parse()</function>呼び出しで処理されるクエリが負荷分散されている場合、バックエンドからのパラメータステータスメッセージの1つだけが処理される可能性がありました。
+ パラメータステータスメッセージは<command>SET</command>コマンドによって生成され、<command>SET</command>コマンドはレプリケーションモードおよびスナップショットアイソレーションモードのすべての生きているバックエンドに送信されるため、すべての生きているバックエンドから送信される可能性がありました。
+ そのため、ParameterStatus()を呼び出す前に、クエリ進行中フラグを設定解除するように修正しました。
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </listitem>
+ </itemizedlist>
+ </sect2>
+</sect1>
+
<sect1 id="release-4-4-8">
<title>リリース 4.4.8</title>
<note>
<!-- doc/src/sgml/release-4.5.sgml -->
<!-- See header comment in release.sgml about typical markup -->
+<sect1 id="release-4-5-4">
+ <title>リリース 4.5.4</title>
+ <note>
+ <title>リリース日</title>
+ <simpara>2024-09-09</simpara>
+ </note>
+
+ <sect2>
+ <title>概要</title>
+ <para>
+ このリリースには、セキュリティ修正が含まれています。
+ </para>
+ <para>
+ クエリキャッシュ機能（<xref linkend="runtime-in-memory-query-cache">）が有効な時に、データベースユーザがクエリキャッシュ経由で本来読み出せない行を読むことが可能でした。(CVE-2024-45624)
+ </para>
+ <para>
+ 4.5.4, 4.4.9, 4.3.12, 4.2.19, 4.1.22より古く、クエリキャッシュ機能を持つすべてのバージョン(クエリキャッシュ機能は3.2で実装されました)がこの脆弱性の影響を受けます。
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ あるユーザのクエリキャッシュがテーブルに対して作成されていると、そのテーブルへのアクセス権がREVOKEコマンドで剥奪されても、アクセス権を持たないそのユーザがクエリキャッシュを通じてテーブルにアクセスすることが可能でした。
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ ユーザAのクエリキャッシュがテーブルに対して作成されていて、同じセッション内でSET ROLEあるいはSET SESSION_AUTHORIZATIONで他のユーザBに切り替えてそのテーブルにアクセスすると、アクセス権を持たないBがクエリキャッシュを通じてアクセスすることが可能でした。
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ ユーザAのクエリキャッシュが行セキュリティが有効なテーブルに対して作成されていて、同じセッション内でSET ROLEあるいはSET SESSION_AUTHORIZATIONで他のユーザBに切り替えてそのテーブルにアクセスすると、本来Bが見えない行をクエリキャッシュを通じて取り出すことが可能でした。
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ Pgpool-II 4.5.4, 4.4.9, 4.3.12, 4.2.19, 4.1.22以降へのアップグレードを強くお勧めします。
+ それができない場合は、クエリキャッシュ機能を無効にしてください。
+ </para>
+ <para>
+ なお、この脆弱性を修正するために、いくつかのコマンド(ALTER DATABASE, ALTER ROLE, ALTER TABLE, REVOKE)を実行すると、クエリキャッシュのすべてのデータを削除するようになりました。
+ これにより、クエリキャッシュの性能に影響があるかも知れません。
+ </para>
+ </sect2>
+
+ <sect2>
+ <title>不具合修正</title>
+ <itemizedlist>
+
+ <listitem>
+ <!--
+ 2024-08-09 [4c2c06f]
+ 2024-08-11 [7a2737c]
+ -->
+ <para>
+ レプリケーションモードとスナップショットアイソレーションモードで発生する複数の不具合を修正しました。(Tatsuo Ishii)
+ </para>
+ <para>
+ 次の不具合を修正しました。
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ レプリケーションモードおよびスナップショットアイソレーションモードでコマンドを実行すると、<productname>Pgpool-II</productname>はクエリ準備完了メッセージを待ちますが、一部のコマンド（<command>SET ROLE</command>など）がパラメータステータスメッセージを生成することを忘れていました。
+ その結果、<productname>Pgpool-II</productname>はクエリ準備完了メッセージの前に他のメッセージが到着したことをエラーとして出力していました。
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 前のクエリがパラメータステータスメッセージを生成した場合、後続の<function>parse()</function>はそれを読み取って処理する必要があります。
+ これは、パラメータステータスメッセージの後に続くはずのクエリ準備完了メッセージを読み取る必要があるためです。
+ </para>
+ <para>
+ ただし、<function>ParameterStatus()</function>が呼び出されると、クエリ進行中フラグが設定され、この<function>parse()</function>呼び出しで処理されるクエリが負荷分散されている場合、バックエンドからのパラメータステータスメッセージの1つだけが処理される可能性がありました。
+ パラメータステータスメッセージは<command>SET</command>コマンドによって生成され、<command>SET</command>コマンドはレプリケーションモードおよびスナップショットアイソレーションモードのすべての生きているバックエンドに送信されるため、すべての生きているバックエンドから送信される可能性がありました。
+ そのため、ParameterStatus()を呼び出す前に、クエリ進行中フラグを設定解除するように修正しました。
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </listitem>
+ </itemizedlist>
+ </sect2>
+</sect1>
+
<sect1 id="release-4-5-3">
<title>リリース 4.5.3</title>
<note>
<!-- doc/src/sgml/release-4.1.sgml -->
<!-- See header comment in release.sgml about typical markup -->
+<sect1 id="release-4-1-22">
+ <title>Release 4.1.22</title>
+ <note>
+ <title>Release Date</title>
+ <simpara>2024-09-09</simpara>
+ </note>
+
+ <sect2>
+ <title>Overview</title>
+ <para>
+ This release contains a security fix.
+ </para>
+ <para>
+ When the query cache (<xref linkend="runtime-in-memory-query-cache">) feature is enabled,
+ it was possible that a database user can read rows from tables that should
+ not be visible for the user through query cache (CVE-2024-45624).
+ </para>
+ <para>
+ All versions of <productname>Pgpool-II</productname> older than
+ 4.5.4, 4.4.9, 4.3.12, 4.2.19, 4.1.22, and all older
+ versions that has the query cache feature (the query cache feature was
+ implemented in 3.2) are affected by the vulnerability.
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ If query cache is created for a table for a user, and then the
+ access right of the table is revoked from the user by
+ <command>REVOKE</command> command, still it was possible for the
+ user to access the table which the user does not have the access
+ right through the query
+ cache.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If query cache is created for a table for user A, and then other
+ user B accesses the table via <command>SET ROLE</command> or
+ <command>SET SESSION_AUTHORIZATION</command> in the same session,
+ still it was possible for the user B to access the table which B
+ does not have the access right through the query
+ cache.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If query cache is created for a row security enabled table for user
+ A, and then other user B accesses the table via <command>SET ROLE</command>
+ or SET <command>SESSION_AUTHORIZATION</command> in the same session,
+ it was possible for the user B to retrieve rows which should not be
+ visible from the user B through the query cache.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ <para>
+ It is strongly recommend to upgrade to <productname>Pgpool-II</productname>
+ 4.5.4, 4.4.9, 4.3.12, 4.2.19 and 4.1.22 or later. Or you should better turn
+ off the query cache feature.
+ </para>
+
+ <para>
+ Note that to fix the vulnerability, some commands (ALTER DATABASE,
+ ALTER ROLE, ALTER TABLE, REVOKE) now invalidate whole query cache
+ data. This may affect the performance when using the query cache
+ feature.
+ </para>
+ </sect2>
+
+ <sect2>
+ <title>Changes</title>
+ <itemizedlist>
+ <listitem>
+ <!--
+ 2024-08-15 [c802c1e]
+ -->
+ <para>
+ Back port <xref linkend="guc-notice-per-node-statement">. (Tatsuo Ishii)
+ </para>
+ <para>
+ This is mainly for testing. Backpatch-through: v4.1
+ </para>
+ <para>
+ Discussion: <ulink url="https://www.pgpool.net/pipermail/pgpool-hackers/2024-August/004505.html">[pgpool-hackers: 4504]</ulink>
+ </para>
+ </listitem>
+ </itemizedlist>
+ </sect2>
+
+ <sect2>
+ <title>Bug fixes</title>
+ <itemizedlist>
+
+ <listitem>
+ <!--
+ 2024-08-09 [e25f5d6]
+ 2024-08-11 [781859a]
+ -->
+ <para>
+ Fix bugs in replication mode and snapshot isolation mode. (Tatsuo Ishii)
+ </para>
+ <para>
+ The following bugs was fixed:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ In replication mode and snapshot isolation mode when a command finishes,
+ <productname>Pgpool-II</productname> waits for a ready for query message
+ but forgot that some commands (for example <command>SET ROLE</command>)
+ produces a parameter status message. As a result
+ <productname>Pgpool-II</productname> errors
+ out that other message arrives before the ready for query message.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If previous query produces parameter status message, subsequent
+ <function>parse()</function> needs to read and process it because
+ it wants to read Ready for query message which is supposed to follow
+ the parameter status message.
+ However when <function>ParameterStatus()</function> gets called,
+ the query in progress flag was set and it was possible that only
+ one of parameter status message from backend was processed if the
+ query processed in this <function>parse()</function> call is load
+ balanced. It is likely that the parameter status message comes from
+ all live backend because they are generated by <command>SET</command>
+ command, and <command>SET</command> command are sent to all live backend
+ in replication mode and snapshot isolation mode. So unset the query in
+ progress flag before calling <function>ParameterStatus()</function>.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+
+ </itemizedlist>
+ </sect2>
+</sect1>
+
<sect1 id="release-4-1-21">
<title>Release 4.1.21</title>
<note>
<!-- doc/src/sgml/release-4.2.sgml -->
<!-- See header comment in release.sgml about typical markup -->
+<sect1 id="release-4-2-19">
+ <title>Release 4.2.19</title>
+ <note>
+ <title>Release Date</title>
+ <simpara>2024-09-09</simpara>
+ </note>
+
+ <sect2>
+ <title>Overview</title>
+ <para>
+ This release contains a security fix.
+ </para>
+ <para>
+ When the query cache (<xref linkend="runtime-in-memory-query-cache">) feature is enabled,
+ it was possible that a database user can read rows from tables that should
+ not be visible for the user through query cache (CVE-2024-45624).
+ </para>
+ <para>
+ All versions of <productname>Pgpool-II</productname> older than
+ 4.5.4, 4.4.9, 4.3.12, 4.2.19, 4.1.22, and all older
+ versions that has the query cache feature (the query cache feature was
+ implemented in 3.2) are affected by the vulnerability.
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ If query cache is created for a table for a user, and then the
+ access right of the table is revoked from the user by
+ <command>REVOKE</command> command, still it was possible for the
+ user to access the table which the user does not have the access
+ right through the query
+ cache.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If query cache is created for a table for user A, and then other
+ user B accesses the table via <command>SET ROLE</command> or
+ <command>SET SESSION_AUTHORIZATION</command> in the same session,
+ still it was possible for the user B to access the table which B
+ does not have the access right through the query
+ cache.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If query cache is created for a row security enabled table for user
+ A, and then other user B accesses the table via <command>SET ROLE</command>
+ or SET <command>SESSION_AUTHORIZATION</command> in the same session,
+ it was possible for the user B to retrieve rows which should not be
+ visible from the user B through the query cache.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ <para>
+ It is strongly recommend to upgrade to <productname>Pgpool-II</productname>
+ 4.5.4, 4.4.9, 4.3.12, 4.2.19 and 4.1.22 or later. Or you should better turn
+ off the query cache feature.
+ </para>
+
+ <para>
+ Note that to fix the vulnerability, some commands (ALTER DATABASE,
+ ALTER ROLE, ALTER TABLE, REVOKE) now invalidate whole query cache
+ data. This may affect the performance when using the query cache
+ feature.
+ </para>
+ </sect2>
+
+ <sect2>
+ <title>Changes</title>
+ <itemizedlist>
+ <listitem>
+ <!--
+ 2024-08-15 [e5f3056]
+ -->
+ <para>
+ Back port <xref linkend="guc-notice-per-node-statement">. (Tatsuo Ishii)
+ </para>
+ <para>
+ This is mainly for testing. Backpatch-through: v4.1
+ </para>
+ <para>
+ Discussion: <ulink url="https://www.pgpool.net/pipermail/pgpool-hackers/2024-August/004505.html">[pgpool-hackers: 4504]</ulink>
+ </para>
+ </listitem>
+ </itemizedlist>
+ </sect2>
+
+ <sect2>
+ <title>Bug fixes</title>
+ <itemizedlist>
+
+ <listitem>
+ <!--
+ 2024-08-09 [7d97cdb]
+ 2024-08-11 [0c10733]
+ -->
+ <para>
+ Fix bugs in replication mode and snapshot isolation mode. (Tatsuo Ishii)
+ </para>
+ <para>
+ The following bugs was fixed:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ In replication mode and snapshot isolation mode when a command finishes,
+ <productname>Pgpool-II</productname> waits for a ready for query message
+ but forgot that some commands (for example <command>SET ROLE</command>)
+ produces a parameter status message. As a result
+ <productname>Pgpool-II</productname> errors
+ out that other message arrives before the ready for query message.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If previous query produces parameter status message, subsequent
+ <function>parse()</function> needs to read and process it because
+ it wants to read Ready for query message which is supposed to follow
+ the parameter status message.
+ However when <function>ParameterStatus()</function> gets called,
+ the query in progress flag was set and it was possible that only
+ one of parameter status message from backend was processed if the
+ query processed in this <function>parse()</function> call is load
+ balanced. It is likely that the parameter status message comes from
+ all live backend because they are generated by <command>SET</command>
+ command, and <command>SET</command> command are sent to all live backend
+ in replication mode and snapshot isolation mode. So unset the query in
+ progress flag before calling <function>ParameterStatus()</function>.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+
+ </itemizedlist>
+ </sect2>
+</sect1>
+
<sect1 id="release-4-2-18">
<title>Release 4.2.18</title>
<note>
<!-- doc/src/sgml/release-4.3.sgml -->
<!-- See header comment in release.sgml about typical markup -->
+<sect1 id="release-4-3-12">
+ <title>Release 4.3.12</title>
+ <note>
+ <title>Release Date</title>
+ <simpara>2024-09-09</simpara>
+ </note>
+
+ <sect2>
+ <title>Overview</title>
+ <para>
+ This release contains a security fix.
+ </para>
+ <para>
+ When the query cache (<xref linkend="runtime-in-memory-query-cache">) feature is enabled,
+ it was possible that a database user can read rows from tables that should
+ not be visible for the user through query cache (CVE-2024-45624).
+ </para>
+ <para>
+ All versions of <productname>Pgpool-II</productname> older than
+ 4.5.4, 4.4.9, 4.3.12, 4.2.19, 4.1.22, and all older
+ versions that has the query cache feature (the query cache feature was
+ implemented in 3.2) are affected by the vulnerability.
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ If query cache is created for a table for a user, and then the
+ access right of the table is revoked from the user by
+ <command>REVOKE</command> command, still it was possible for the
+ user to access the table which the user does not have the access
+ right through the query
+ cache.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If query cache is created for a table for user A, and then other
+ user B accesses the table via <command>SET ROLE</command> or
+ <command>SET SESSION_AUTHORIZATION</command> in the same session,
+ still it was possible for the user B to access the table which B
+ does not have the access right through the query
+ cache.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If query cache is created for a row security enabled table for user
+ A, and then other user B accesses the table via <command>SET ROLE</command>
+ or SET <command>SESSION_AUTHORIZATION</command> in the same session,
+ it was possible for the user B to retrieve rows which should not be
+ visible from the user B through the query cache.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ <para>
+ It is strongly recommend to upgrade to <productname>Pgpool-II</productname>
+ 4.5.4, 4.4.9, 4.3.12, 4.2.19 and 4.1.22 or later. Or you should better turn
+ off the query cache feature.
+ </para>
+
+ <para>
+ Note that to fix the vulnerability, some commands (ALTER DATABASE,
+ ALTER ROLE, ALTER TABLE, REVOKE) now invalidate whole query cache
+ data. This may affect the performance when using the query cache
+ feature.
+ </para>
+ </sect2>
+
+ <sect2>
+ <title>Changes</title>
+ <itemizedlist>
+ <listitem>
+ <!--
+ 2024-08-15 [907d91c]
+ -->
+ <para>
+ Back port <xref linkend="guc-notice-per-node-statement">. (Tatsuo Ishii)
+ </para>
+ <para>
+ This is mainly for testing. Backpatch-through: v4.1
+ </para>
+ <para>
+ Discussion: <ulink url="https://www.pgpool.net/pipermail/pgpool-hackers/2024-August/004505.html">[pgpool-hackers: 4504]</ulink>
+ </para>
+ </listitem>
+ </itemizedlist>
+ </sect2>
+
+ <sect2>
+ <title>Bug fixes</title>
+ <itemizedlist>
+
+ <listitem>
+ <!--
+ 2024-08-09 [01c7229]
+ 2024-08-11 [fbecbd9]
+ -->
+ <para>
+ Fix bugs in replication mode and snapshot isolation mode. (Tatsuo Ishii)
+ </para>
+ <para>
+ The following bugs was fixed:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ In replication mode and snapshot isolation mode when a command finishes,
+ <productname>Pgpool-II</productname> waits for a ready for query message
+ but forgot that some commands (for example <command>SET ROLE</command>)
+ produces a parameter status message. As a result
+ <productname>Pgpool-II</productname> errors
+ out that other message arrives before the ready for query message.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If previous query produces parameter status message, subsequent
+ <function>parse()</function> needs to read and process it because
+ it wants to read Ready for query message which is supposed to follow
+ the parameter status message.
+ However when <function>ParameterStatus()</function> gets called,
+ the query in progress flag was set and it was possible that only
+ one of parameter status message from backend was processed if the
+ query processed in this <function>parse()</function> call is load
+ balanced. It is likely that the parameter status message comes from
+ all live backend because they are generated by <command>SET</command>
+ command, and <command>SET</command> command are sent to all live backend
+ in replication mode and snapshot isolation mode. So unset the query in
+ progress flag before calling <function>ParameterStatus()</function>.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+
+ </itemizedlist>
+ </sect2>
+</sect1>
+
<sect1 id="release-4-3-11">
<title>Release 4.3.11</title>
<note>
<!-- doc/src/sgml/release-4.4.sgml -->
<!-- See header comment in release.sgml about typical markup -->
+<sect1 id="release-4-4-9">
+ <title>Release 4.4.9</title>
+ <note>
+ <title>Release Date</title>
+ <simpara>2024-09-09</simpara>
+ </note>
+
+ <sect2>
+ <title>Overview</title>
+ <para>
+ This release contains a security fix.
+ </para>
+ <para>
+ When the query cache (<xref linkend="runtime-in-memory-query-cache">) feature is enabled,
+ it was possible that a database user can read rows from tables that should
+ not be visible for the user through query cache (CVE-2024-45624).
+ </para>
+ <para>
+ All versions of <productname>Pgpool-II</productname> older than
+ 4.5.4, 4.4.9, 4.3.12, 4.2.19, 4.1.22, and all older
+ versions that has the query cache feature (the query cache feature was
+ implemented in 3.2) are affected by the vulnerability.
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ If query cache is created for a table for a user, and then the
+ access right of the table is revoked from the user by
+ <command>REVOKE</command> command, still it was possible for the
+ user to access the table which the user does not have the access
+ right through the query
+ cache.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If query cache is created for a table for user A, and then other
+ user B accesses the table via <command>SET ROLE</command> or
+ <command>SET SESSION_AUTHORIZATION</command> in the same session,
+ still it was possible for the user B to access the table which B
+ does not have the access right through the query
+ cache.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If query cache is created for a row security enabled table for user
+ A, and then other user B accesses the table via <command>SET ROLE</command>
+ or SET <command>SESSION_AUTHORIZATION</command> in the same session,
+ it was possible for the user B to retrieve rows which should not be
+ visible from the user B through the query cache.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ <para>
+ It is strongly recommend to upgrade to <productname>Pgpool-II</productname>
+ 4.5.4, 4.4.9, 4.3.12, 4.2.19 and 4.1.22 or later. Or you should better turn
+ off the query cache feature.
+ </para>
+
+ <para>
+ Note that to fix the vulnerability, some commands (ALTER DATABASE,
+ ALTER ROLE, ALTER TABLE, REVOKE) now invalidate whole query cache
+ data. This may affect the performance when using the query cache
+ feature.
+ </para>
+ </sect2>
+
+ <sect2>
+ <title>Changes</title>
+ <itemizedlist>
+ <listitem>
+ <!--
+ 2024-08-15 [730acde]
+ -->
+ <para>
+ Back port <xref linkend="guc-notice-per-node-statement">. (Tatsuo Ishii)
+ </para>
+ <para>
+ This is mainly for testing. Backpatch-through: v4.1
+ </para>
+ <para>
+ Discussion: <ulink url="https://www.pgpool.net/pipermail/pgpool-hackers/2024-August/004505.html">[pgpool-hackers: 4504]</ulink>
+ </para>
+ </listitem>
+ </itemizedlist>
+ </sect2>
+
+ <sect2>
+ <title>Bug fixes</title>
+ <itemizedlist>
+
+ <listitem>
+ <!--
+ 2024-08-09 [1f200d7]
+ 2024-08-11 [ce7ed50]
+ -->
+ <para>
+ Fix bugs in replication mode and snapshot isolation mode. (Tatsuo Ishii)
+ </para>
+ <para>
+ The following bugs was fixed:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ In replication mode and snapshot isolation mode when a command finishes,
+ <productname>Pgpool-II</productname> waits for a ready for query message
+ but forgot that some commands (for example <command>SET ROLE</command>)
+ produces a parameter status message. As a result
+ <productname>Pgpool-II</productname> errors
+ out that other message arrives before the ready for query message.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If previous query produces parameter status message, subsequent
+ <function>parse()</function> needs to read and process it because
+ it wants to read Ready for query message which is supposed to follow
+ the parameter status message.
+ However when <function>ParameterStatus()</function> gets called,
+ the query in progress flag was set and it was possible that only
+ one of parameter status message from backend was processed if the
+ query processed in this <function>parse()</function> call is load
+ balanced. It is likely that the parameter status message comes from
+ all live backend because they are generated by <command>SET</command>
+ command, and <command>SET</command> command are sent to all live backend
+ in replication mode and snapshot isolation mode. So unset the query in
+ progress flag before calling <function>ParameterStatus()</function>.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+
+ </itemizedlist>
+ </sect2>
+</sect1>
+
<sect1 id="release-4-4-8">
<title>Release 4.4.8</title>
<note>
+<sect1 id="release-4-5-4">
+ <title>Release 4.5.4</title>
+ <note>
+ <title>Release Date</title>
+ <simpara>2024-09-09</simpara>
+ </note>
+
+ <sect2>
+ <title>Overview</title>
+ <para>
+ This release contains a security fix.
+ </para>
+ <para>
+ When the query cache (<xref linkend="runtime-in-memory-query-cache">) feature is enabled,
+ it was possible that a database user can read rows from tables that should
+ not be visible for the user through query cache (CVE-2024-45624).
+ </para>
+ <para>
+ All versions of <productname>Pgpool-II</productname> older than
+ 4.5.4, 4.4.9, 4.3.12, 4.2.19, 4.1.22, and all older
+ versions that has the query cache feature (the query cache feature was
+ implemented in 3.2) are affected by the vulnerability.
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ If query cache is created for a table for a user, and then the
+ access right of the table is revoked from the user by
+ <command>REVOKE</command> command, still it was possible for the
+ user to access the table which the user does not have the access
+ right through the query
+ cache.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If query cache is created for a table for user A, and then other
+ user B accesses the table via <command>SET ROLE</command> or
+ <command>SET SESSION_AUTHORIZATION</command> in the same session,
+ still it was possible for the user B to access the table which B
+ does not have the access right through the query
+ cache.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If query cache is created for a row security enabled table for user
+ A, and then other user B accesses the table via <command>SET ROLE</command>
+ or SET <command>SESSION_AUTHORIZATION</command> in the same session,
+ it was possible for the user B to retrieve rows which should not be
+ visible from the user B through the query cache.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ <para>
+ It is strongly recommend to upgrade to <productname>Pgpool-II</productname>
+ 4.5.4, 4.4.9, 4.3.12, 4.2.19 and 4.1.22 or later. Or you should better turn
+ off the query cache feature.
+ </para>
+
+ <para>
+ Note that to fix the vulnerability, some commands (ALTER DATABASE,
+ ALTER ROLE, ALTER TABLE, REVOKE) now invalidate whole query cache
+ data. This may affect the performance when using the query cache
+ feature.
+ </para>
+ </sect2>
+
+ <sect2>
+ <title>Bug fixes</title>
+ <itemizedlist>
+
+ <listitem>
+ <!--
+ 2024-08-09 [4c2c06f]
+ 2024-08-11 [7a2737c]
+ -->
+ <para>
+ Fix bugs in replication mode and snapshot isolation mode. (Tatsuo Ishii)
+ </para>
+ <para>
+ The following bugs was fixed:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ In replication mode and snapshot isolation mode when a command finishes,
+ <productname>Pgpool-II</productname> waits for a ready for query message
+ but forgot that some commands (for example <command>SET ROLE</command>)
+ produces a parameter status message. As a result
+ <productname>Pgpool-II</productname> errors
+ out that other message arrives before the ready for query message.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If previous query produces parameter status message, subsequent
+ <function>parse()</function> needs to read and process it because
+ it wants to read Ready for query message which is supposed to follow
+ the parameter status message.
+ However when <function>ParameterStatus()</function> gets called,
+ the query in progress flag was set and it was possible that only
+ one of parameter status message from backend was processed if the
+ query processed in this <function>parse()</function> call is load
+ balanced. It is likely that the parameter status message comes from
+ all live backend because they are generated by <command>SET</command>
+ command, and <command>SET</command> command are sent to all live backend
+ in replication mode and snapshot isolation mode. So unset the query in
+ progress flag before calling <function>ParameterStatus()</function>.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+
+ </itemizedlist>
+ </sect2>
+</sect1>
+
<sect1 id="release-4-5-3">
<title>Release 4.5.3</title>
<note>
projects / pgpool2.git / commitdiff