<sect2>
<title>変更点</title>
<itemizedlist>
- <listitem>
- <!--
- 2023-04-18 [ea63203]
- -->
- <para>
- マルチステートメントのクエリを判定するために、<literal>psqlscan</literal>のソースコードを<productname>Pgpool-II</productname>にインポートしました。(Tatsuo Ishii)
- </para>
- <para>
- <literal>psqlscan</literal>は、<productname>PostgreSQL</productname>ソースツリー内のモジュールです。
- これは本質的にPostgreSQL SQLスキャナのサブセットですが、各SQLステートメントの終わりの検出に特化しています。
- したがって、これを使用してクエリ文字列内のSQLステートメントの数をカウントできます。
- </para>
- <para>
- 議論: <ulink url="https://www.pgpool.net/pipermail/pgpool-hackers/2023-February/004291.html">https://www.pgpool.net/pipermail/pgpool-hackers/2023-February/04291.html</ulink>
- 議論: <ulink url="https://www.pgpool.net/pipermail/pgpool-hackers/2023-April/004320.html">https://www.pgpool.net/pipermail/pgpool-hackers/2023-April/004320.html</ulink>
- </para>
- </listitem>
-
- <listitem>
- <!--
- 2023-04-09 [f6ab7be]
- 2023-02-15 [4afb7d5]
- -->
- <para>
- 複数のステートメントを幅広く使用できるようにしました。 (Tatsuo Ishii)
- </para>
- <para>
- このコミットは、複数のステートメント (マルチステートメント) に関する<productname>Pgpool-II</productname>の長年の制限を排除しました。
- </para>
- <para>
- 議論: <ulink url="https://www.pgpool.net/pipermail/pgpool-hackers/2023-February/004287.html">https://www.pgpool.net/pipermail/pgpool-hackers/2023-February/004287.html</ulink>
- </para>
- </listitem>
-
<listitem>
<!--
2023-04-16 [51e6174]
<sect2>
<title>不具合修正</title>
<itemizedlist>
- <listitem>
- <!--
- 2023-05-12 [21d2945]
- -->
- <para>
- 共有リレーションキャッシュで発生しうるデッドロックを修正しました。(Tatsuo Ishii)
- </para>
- <para>
- ユーザー定義関数がテーブルロックを取得する場合、拡張クエリプロトコルを使用して関数を呼び出すとデッドロックが発生する可能性がありました。
- 以下にシナリオを示します。
- <itemizedlist>
- <listitem>
- <para>
- (1) セッション中クライアントはparse、bind、executeリクエストをpgpoolに送信します。
- </para>
- </listitem>
- </itemizedlist>
- <itemizedlist>
- <listitem>
- <para>
- (2) セッションAのPgpool-IIはリクエストをPostgreSQLに転送します。
- </para>
- </listitem>
- </itemizedlist>
- <itemizedlist>
- <listitem>
- <para>
- (3) セッションAのPostgreSQLがexecuteを実行し、テーブルロックが発生します。
- </para>
- </listitem>
- </itemizedlist>
- <itemizedlist>
- <listitem>
- <para>
- (4) セッションBで、クライアントは関数のparse、bind、executeリクエストをpgpoolに送信します。
- </para>
- </listitem>
- </itemizedlist>
- <itemizedlist>
- <listitem>
- <para>
- (5) セッションBのPgpoolはリクエストをPostgreSQLに転送します。
- </para>
- </listitem>
- </itemizedlist>
- <itemizedlist>
- <listitem>
- <para>
- (6) セッションBのPostgreSQLはbindを実行しますが、テーブルはセッションAのPostgreSQLによってすでにロックされており、ロックの解放を待ちます。
- </para>
- </listitem>
- </itemizedlist>
- <itemizedlist>
- <listitem>
- <para>
- (7) セッションBのpgpoolはexecuteをPostgreSQLに転送した後、関数の揮発性をチェックするために共有リレーションキャッシュを検索するためのセマフォを取得します。
- 次に、do_queryを呼び出し、フラッシュメッセージをPostgreSQLに送信して、この時点までのPostgreSQLからの応答を取得します。
- ただし、#6ではPostgreSQLがテーブルロックを待機しているため、pgpoolはバインド完了後のメッセージを待つ必要があります。
- </para>
- </listitem>
- </itemizedlist>
- <itemizedlist>
- <listitem>
- <para>
- (8) セッションAのpgpoolがPostgreSQLにexecuteを転送した後、関数の揮発性をチェックするために共有リレーションキャッシュを検索しセマフォを取得しようとしましたが、セマフォはセッションBのpgpoolによってすでに取得されているため、セマフォの解放を待ちます。
- </para>
- </listitem>
- </itemizedlist>
- <itemizedlist>
- <listitem>
- <para>
- (9) セッションAとセッションBがお互いを待機するため、デッドロックが発生します。
- </para>
- </listitem>
- </itemizedlist>
- </para>
- <para>
- これを修正するには、do_query()を呼び出す前にセマフォを解放するようにpool_search_relcache()を変更しました(ただし、セマフォはdo_query()の後に取得します)。
- これにより、上記#8のセッションAはセマフォを取得し、先に進むことができます。
- クライアントからsyncメッセージを受信し、PostgreSQLに転送します。
- syncを受信すると、ユーザ定義関数は実行を終了し、テーブルロックを解放します。
- これにより、セッションBのPostgreSQLがテーブルロックを取得できるようになります。
- </para>
- </listitem>
-
<listitem>
<!--
2023-03-22 [f18b58a]
<itemizedlist>
<listitem>
<!--
- 2023-04-18 [ea63203]
- -->
- <para>
- Import <literal>psqlscan</literal> source code into <productname>Pgpool-II</productname> to judge multi statement query. (Tatsuo Ishii)
- </para>
- <para>
- <literal>Psqlscan</literal> is a module in the PostgreSQL source tree.
- It is essentially subset of <productname>PostgreSQL</productname> SQL scanner
- but it is specialized for detecting
- the end of each SQL statement. Therefore we can count the number of
- SQL statements in a query string by using it.
- </para>
- <para>
- Discussion: <ulink url="https://www.pgpool.net/pipermail/pgpool-hackers/2023-February/004291.html">https://www.pgpool.net/pipermail/pgpool-hackers/2023-February/04291.html</ulink>
- Discussion: <ulink url="https://www.pgpool.net/pipermail/pgpool-hackers/2023-April/004320.html">https://www.pgpool.net/pipermail/pgpool-hackers/2023-April/004320.html</ulink>
- </para>
- </listitem>
-
- <listitem>
- <!--
- 2023-04-09 [f6ab7be]
- 2023-02-15 [4afb7d5]
- -->
- <para>
- Allow to use multiple statements extensively. (Tatsuo Ishii)
- </para>
- <para>
- This commit tries to eliminate pgpool's long standing limitations
- regarding multiple statements (multi-statements).
- </para>
- <para>
- Discussion: <ulink url="https://www.pgpool.net/pipermail/pgpool-hackers/2023-February/004287.html">https://www.pgpool.net/pipermail/pgpool-hackers/2023-February/004287.html</ulink>
- </para>
- </listitem>
-
- <listitem>
- <!--
- 2023-04-16 [51e6174]
2023-03-30 [a508d33]
2023-03-28 [687f6c0]
-->
<sect2>
<title>Bug fixes</title>
<itemizedlist>
- <listitem>
- <!--
- 2023-05-12 [e178e03]
- -->
- <para>
- Fix possible dead lock with shared relation cache. (Tatsuo Ishii)
- </para>
- <para>
- When a user defined function obtains table locking, call to the
- function using extended query protocol could lead to dead lock. Here's
- a scenario:
- <itemizedlist>
- <listitem>
- <para>
- (1) In session A client sends parse, bind, execute request for the function to pgpool.
- </para>
- </listitem>
- </itemizedlist>
- <itemizedlist>
- <listitem>
- <para>
- (2) <productname>Pgpool-II</productname> in session A forwards
- the request to <productname>PostgreSQL</productname>.
- </para>
- </listitem>
- </itemizedlist>
- <itemizedlist>
- <listitem>
- <para>
- (3) PostgreSQL in session A performs execute, resulting in a table lock.
- </para>
- </listitem>
- </itemizedlist>
- <itemizedlist>
- <listitem>
- <para>
- (4) In session B client sends parse, bind, execute request for the
- function to pgpool.
- </para>
- </listitem>
- </itemizedlist>
- <itemizedlist>
- <listitem>
- <para>
- (5) Pgpool in session B forwards the request to PostgreSQL.
- </para>
- </listitem>
- </itemizedlist>
- <itemizedlist>
- <listitem>
- <para>
- (6) PostgreSQL in session B performs bind but the table was already
- locked by PostgreSQL in session A, and it waits for release of the
- lock.
- </para>
- </listitem>
- </itemizedlist>
- <itemizedlist>
- <listitem>
- <para>
- (7) After pgpool in session B forwards the execute to PostgreSQL, it
- acquires semaphore to search shared relation cache to check the
- volatility of the function. Then it calls do_query and sends flush
- message to PostgreSQL to obtain the response from PostgreSQL up to
- this point. But since PostgreSQL is waiting for table lock in #6,
- pgpool has to wait for messages beyond bind complete.
- </para>
- </listitem>
- </itemizedlist>
- <itemizedlist>
- <listitem>
- <para>
- (8) After pgpool in session A forwards the execute to PostgreSQL, it
- tries to acquire semaphore to search shared relation cache to check
- the volatility of the function but the semaphore was already
- acquired by pgpool in session B, it waits for the release of the
- semaphore.
- </para>
- </listitem>
- </itemizedlist>
- <itemizedlist>
- <listitem>
- <para>
- (9) Session A and session B wait for each other, resulting in a dead lock.
- </para>
- </listitem>
- </itemizedlist>
- </para>
- <para>
- To fix this, modify pool_search_relcache() so that it releases
- semaphore before calling do_query() (but acquires semaphore after
- do_query()). By this, session A in #8 above can get semaphore, and go
- forward. It receives sync message from client and forwards it to
- PostgreSQL. Upon receiving sync, the user defined function will finish
- the execution and releases the table lock. This makes PostgreSQL in
- session B move forward because now it can obtain the table lock.
- </para>
- </listitem>
-
<listitem>
<!--
2023-03-22 [f18b58a]
projects / pgpool2.git / commitdiff