Doc: add release notes.

diff --git a/doc.ja/src/sgml/release-4.1.sgml b/doc.ja/src/sgml/release-4.1.sgml
index ebe8259b26313d1dcdc9b1d7283058aa4ea7b2a0..9d35a591959d86155b050566119274d24efc393d 100644 (file)
--- a/doc.ja/src/sgml/release-4.1.sgml
+++ b/doc.ja/src/sgml/release-4.1.sgml
@@ -1,6 +1,115 @@
 <!-- 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>

diff --git a/doc.ja/src/sgml/release-4.2.sgml b/doc.ja/src/sgml/release-4.2.sgml
index 00a3d5abdf87b349bf693c25fa50444d0b254989..c3d545841bbab2db49a9f5ff6ec5398f60ff89f5 100644 (file)
--- a/doc.ja/src/sgml/release-4.2.sgml
+++ b/doc.ja/src/sgml/release-4.2.sgml
@@ -1,6 +1,115 @@
 <!-- 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>

diff --git a/doc.ja/src/sgml/release-4.3.sgml b/doc.ja/src/sgml/release-4.3.sgml
index 605fd0d56194544508cd92fd67c8c049087e2fcc..c48c02f5f53dae1431748e838ab26e83be5a05aa 100644 (file)
--- a/doc.ja/src/sgml/release-4.3.sgml
+++ b/doc.ja/src/sgml/release-4.3.sgml
@@ -1,6 +1,115 @@
 <!-- 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>

diff --git a/doc.ja/src/sgml/release-4.4.sgml b/doc.ja/src/sgml/release-4.4.sgml
index 9802ced461a2a144da7b6a2695ee1590df53dc6b..9397d031372fcd89ef0469d11280022c0d8b1d63 100644 (file)
--- a/doc.ja/src/sgml/release-4.4.sgml
+++ b/doc.ja/src/sgml/release-4.4.sgml
@@ -1,6 +1,115 @@
 <!-- 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>

diff --git a/doc.ja/src/sgml/release-4.5.sgml b/doc.ja/src/sgml/release-4.5.sgml
index dcf598ca6489ada001586b9be0018dff5eaa6ee4..71cd0d1a11936b91f50bc36567b20bab507cec8f 100644 (file)
--- a/doc.ja/src/sgml/release-4.5.sgml
+++ b/doc.ja/src/sgml/release-4.5.sgml
@@ -1,6 +1,95 @@
 <!-- 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>

diff --git a/doc/src/sgml/release-4.1.sgml b/doc/src/sgml/release-4.1.sgml
index 55cb1c1fc3c81f8bb03977a502edd8755c2a7406..688de7aebb64f0e28a7aad03618e805df48818b4 100644 (file)
--- a/doc/src/sgml/release-4.1.sgml
+++ b/doc/src/sgml/release-4.1.sgml
@@ -1,6 +1,149 @@
 <!-- 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>

diff --git a/doc/src/sgml/release-4.2.sgml b/doc/src/sgml/release-4.2.sgml
index aa978656cf4cc70bbc491510f056139fdbfe4a6e..f8024356d181c9cb06492e77b35e104c0db58aa8 100644 (file)
--- a/doc/src/sgml/release-4.2.sgml
+++ b/doc/src/sgml/release-4.2.sgml
@@ -1,6 +1,149 @@
 <!-- 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>

diff --git a/doc/src/sgml/release-4.3.sgml b/doc/src/sgml/release-4.3.sgml
index fa589c3c8774cd0f3b7a1e80af8b44d8dde2098a..9a8c745fa086787322196688154ffad3f212a8df 100644 (file)
--- a/doc/src/sgml/release-4.3.sgml
+++ b/doc/src/sgml/release-4.3.sgml
@@ -1,6 +1,149 @@
 <!-- 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>

diff --git a/doc/src/sgml/release-4.4.sgml b/doc/src/sgml/release-4.4.sgml
index 1fe0cfd18f89237aaeb90039b493b540e4b558dd..222640f1ecd70e661415260f1eccc2d72a03d9be 100644 (file)
--- a/doc/src/sgml/release-4.4.sgml
+++ b/doc/src/sgml/release-4.4.sgml
@@ -1,6 +1,149 @@
 <!-- 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>

diff --git a/doc/src/sgml/release-4.5.sgml b/doc/src/sgml/release-4.5.sgml
index db16941144c79f123280c8f15ef21c69cdb872cf..3f086f31cfdab81caf65405b419e0d2ac68fce5b 100644 (file)
--- a/doc/src/sgml/release-4.5.sgml
+++ b/doc/src/sgml/release-4.5.sgml
@@ -1,3 +1,126 @@
+<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>