pgpool2.git / summary / log / commit / refs
commit a76c910f6a8f787eda270d3db0e4b99a8d186527
Author: pengbo <pengbo@sraoss.co.jp>
Date: Tue Nov 01 12:53:04 2016 +0000
add Japanese 3.6 releasenote
doc.ja/src/sgml/reference.sgml | 6 +
doc.ja/src/sgml/release-3.6.sgml | 880 ++++++++++++++++++++++++++-------------
doc.ja/src/sgml/release.sgml | 19 +-
doc/src/sgml/release-3.6.sgml | 274 +-----------
4 files changed, 641 insertions(+), 538 deletions(-)
diff --git a/doc.ja/src/sgml/reference.sgml b/doc.ja/src/sgml/reference.sgml
index f50b9061f..2777cfb10 100644
--- a/doc.ja/src/sgml/reference.sgml
+++ b/doc.ja/src/sgml/reference.sgml
@@ -157,7 +157,10 @@ hostname:port:username:password
</reference>
<reference id="other-commands">
+ <!--
<title>Other commands</title>
+ -->
+ <title>他のコマンド</title>
<partintro>
<para>
@@ -176,7 +179,10 @@ hostname:port:username:password
</reference>
<reference id="sql-commands">
+ <!--
<title>SQL type commands</title>
+ -->
+ <title>SQL 型コマンド</title>
<partintro>
<para>
diff --git a/doc.ja/src/sgml/release-3.6.sgml b/doc.ja/src/sgml/release-3.6.sgml
index b1cb6fc0e..3f629db91 100644
--- a/doc.ja/src/sgml/release-3.6.sgml
+++ b/doc.ja/src/sgml/release-3.6.sgml
@@ -2,7 +2,10 @@
<!-- See header comment in release.sgml about typical markup -->
<sect1 id="release-3-6">
+<!--
<title>Release 3.6</title>
+ -->
+ <title>リリース 3.6</title>
<note>
<title>Release Date</title>
@@ -10,10 +13,16 @@
</note>
<sect2>
+ <!--
<title>Overview</title>
+ -->
+ <title>概要</title>
<para>
+ <!--
Major enhancements in <productname>Pgpool-II</productname> 3.6 include:
+ -->
+ <productname>Pgpool-II</productname> 3.6 の主な改善点が以下のとおりです。
</para>
<!-- Items in this list summarize one or more items below -->
@@ -21,7 +30,7 @@
<itemizedlist>
<listitem>
- <para>
+ <!--
Improve the behavior of fail-over. In the steaming
replication mode, client sessions will not be disconnected
when a fail-over occurs any more if the session does not use
@@ -31,61 +40,97 @@
it is doing health checking retries. Before all attempt of
connecting to <productname>Pgpool-II</productname> failed
while doing health checking retries.
- </para>
+ -->
+ <para>
+ fail-over の挙動が改善されました。
+ </para>
+ <para>
+ Streaming Replication モードで、フェイルオーバーが発生した時に、
+ ダウンしたスタンバイサーバを利用しなければ、クライアントセッションが切断されなくなります。
+ プライマリサーバがダウンした場合、すべてのセッションが切断されます。
+ また、ヘルスチェックのリトライの最中でも <productname>Pgpool-II</productname>
+ に接続することが可能です。<productname>Pgpool-II</productname> への接続リトライする最大回数まで
+ ヘルスチェックのリトライが続きます。
+ </para>
</listitem>
<listitem>
<para>
+ <!--
New PGPOOL SET command has been introduced. Certain
configuration parameters now can be changed on the fly in a
session.
+ -->
+ 新しいコマンド <link linkend="SQL-PGPOOL-SET">PGPOOL SET</link> が追加されました。
+ このコマンドを使用することで、現行セッション内で設定パラメータを変更することができるようになりました。
</para>
</listitem>
<listitem>
<para>
+ <!--
Watchdog is significantly enhanced. It becomes more reliable
than previous releases.
+ -->
+ Watchdog の性能が大幅に改善されました。
</para>
</listitem>
<listitem>
<para>
+ <!--
Handling of extended query protocol (e.g. used by Java
applications) in streaming replication mode speeds up if
many rows are returned in a result set.
+ -->
+ 問合せから大量の行が返される場合、拡張問い合わせプロトコル（例えば、Java アプリケーションで使用される場合）の処理速動が改善されました。
</para>
</listitem>
<listitem>
<para>
+ <!--
Import parser of PostgreSQL 9.6.
+ -->
+ PostgreSQL 9.6 のパーサを取り込みました。
</para>
</listitem>
<listitem>
<para>
+ <!--
In some cases pg_terminate_backend() now does not trigger a
fail-over.
+ -->
+ 特定の場合で、<function>pg_terminate_backend()</function> がフェイルオーバを起こさないようになりました。
</para>
</listitem>
<listitem>
<para>
+ <!--
Change documentation format from raw HTML to SGML.
+ -->
+ ドキュメントの形式が HTML から SGML に変更されました。
</para>
</listitem>
</itemizedlist>
<para>
+ <!--
The above items are explained in more detail in the sections below.
+ -->
+ 上記の項目が以下のセクションで詳しく説明します。
</para>
</sect2>
<sect2>
+ <!--
<title>Major Enhancements</title>
+ -->
+ <title>主な改善点</title>
<itemizedlist>
@@ -96,9 +141,13 @@
2016-05-05 [0d66032] Allow to access to pgpool while doing health checking
-->
<para>
+ <!--
Improve the behavior of fail-over. (Tatsuo Ishii)
+ -->
+ fail-over の挙動が改善されました。(Tatsuo Ishii)
</para>
<para>
+ <!--
In the steaming replication mode, client sessions will not
be disconnected when a fail-over occurs any more if the
session does not use the failed standby server. If the
@@ -107,17 +156,31 @@
full session disconnection. Other health check error,
including retry over case does not trigger full session
disconnection.
+ -->
+ Streaming Replication モードで、フェイルオーバーが発生した時に、
+ ダウンしたスタンバイサーバを使用しなければ、クライアントセッションが切断されなくなります。
+ プライマリサーバがダウンした場合、すべてのセッションが切断されます。
+ ヘルスチェックタイムアウトした場合では、すべてのセッションが切断されます。
+ リトライ最大回数を超た場合を含めて他のヘルスチェックエラーが発生する場合、
+ すべてのセッションの切断されません。
</para>
<para>
+ <!--
For user's convenience, "show pool_nodes" command shows the
session local load balance node info since this is important
for users in case of fail-over. If the load balance node is
not the failed node, the session will not be affected by
fail-over.
+ -->
+ fail-over が発生する場合にローカル負荷分散ノードの情報が重要であるので、
+ <command>show pool_nodes</command> コマンドで、
+ ローカル負荷分散ノードの情報が表示されるようになりました。
+ 負荷分散ノードがダウンしたノードではない場合、フェイルオーバーにより影響がありません。
</para>
<para>
+ <!--
Also now it is possible to connect
to <productname>Pgpool-II</productname> even if it is doing
health checking retries. Before all attempt of connecting
@@ -136,23 +199,50 @@
of <xref linkend="guc-health-check-max-retries"> and
<xref linkend="guc-health-check-retry-delay">. This is not
good. Attached patch tries to mitigate the problem:
+ -->
+ また、ヘルスチェックのリトライの最中でも <productname>Pgpool-II</productname> に接続できるようになりました。
+ <productname>Pgpool-II</productname> への接続リトライする最大回数までヘルスチェックのリトライが続きます。
+ fail_over_on_backend_errorが off になっている場合でも、
+ Pgpool-II の子プロセスがまず失敗したバックエンドを含めてすべてのバックエンドへの接続を試み、
+ 失敗した場合終了するため（もちろん失敗します）、<productname>Pgpool-II</productname> へ接続の再試行が失敗するまで、
+ 失敗したノードに対してヘルスチェックを行っています。
+ これは一時的な状況であり、<productname>Pgpool-II</productname> がフェールオーバーを行うする前に解決されます。
+ しかし、ヘルスチェックの再試行が行っている場合は、この一時的な状況の続く時間は、
+ <xref linkend="guc-health-check-max-retries"> と <xref linkend="guc-health-check-retry-delay"> の設定に依存します。
+ この状況が良くないのて、以下のように修正しました。
+
</para>
<para>
+ <!--
When an attempt to connect to backend fails, give up
connecting to the failed node and skip to other node, rather
than exiting the process if operating in streaming
replication mode and the node is not primary node.
+ -->
+ ストリーミングレプリケーションモード、ダウンしたノードがスタンバイの場合、
+ バックエンドへの接続が失敗したら、このバックエンドへの接続をあきらめて、
+ 他のノードへの接続を試みます。
</para>
<para>
+ <!--
Mark the local status of the failed node to "down". This
will let the primary node be selected as a load balance node
and every queries will be sent to the primary node. If
there's other healthy standby nodes, one of them will be
chosen as the load balance node.
+ -->
+ ローカルノードのステータスを down と記録します。
+ プライマリーノードがロードバランスノードとして選択され、
+ すべてのクエリがプライマリーノードへ転送されます。
+ 他のスタンバイのノードが存在する場合、その中からロードバランスノードが選択されます。
</para>
<para>
+ <!--
After the session is over, the child process will suicide to
not retain the local status.
+ -->
+ セッションが終了した後、子プロセスが殺され、ローカルの状態を保持しません。
+
</para>
</listitem>
@@ -162,13 +252,21 @@
2016-05-11 [25dc79e] Adding new SHOW command for pgpool-II configuration parameters.
-->
<para>
+ <!--
Add <link linkend="SQL-PGPOOL-SHOW">PGPOOL
SHOW</link>, <link linkend="SQL-PGPOOL-SET">PGPOOL
SET</link> and
<link linkend="SQL-PGPOOL-RESET">PGPOOL RESET</link>
commands. (Muhammad Usama)
+ -->
+ <link linkend="SQL-PGPOOL-SHOW">PGPOOL
+ SHOW</link>, <link linkend="SQL-PGPOOL-SET">PGPOOL
+ SET</link> と
+ <link linkend="SQL-PGPOOL-RESET">PGPOOL RESET</link>
+ コマンドが追加されました。 (Muhammad Usama)
</para>
<para>
+ <!--
These are similar to the PostgreSQL's SET and SHOW commands
for GUC variables, adding the functionality
in <productname>Pgpool-II</productname> to set and reset the
@@ -177,10 +275,16 @@
in <productname>Pgpool-II</productname> which is similar to
PostgreSQL's SET and RESET variable syntax with an addition
of <literal>PGPOOL</literal> keyword at the start.
+ -->
+ <productname>PostgreSQL</productname> の SET、SHOW と RESET コマンドと似っていますが、
+ PostgreSQL のコマンドと区別するために、 PGPOOL というキーワードが前に挿入しなければなりません。
</para>
<para>
+ <!--
Currently supported configuration parameters by PGPOOL
SHOW/SET/RESET are: <xref linkend="guc-log-statement">,
+ -->
+ 現在 PGPOOL SHOW/SET/RESET に対応している設定パラメータは：
<xref linkend="guc-log-per-node-statement">, <xref linkend="guc-check-temp-table">,
<xref linkend="guc-check-unlogged-table">, <xref linkend="guc-allow-sql-comments">,
<xref linkend="guc-client-idle-limit">, <xref linkend="guc-log-error-verbosity">,
@@ -196,39 +300,20 @@
restart. Watchdog not syncing status.
-->
<para>
+ <!--
Sync inconsitent status
of <productname>PostgreSQL</productname> nodes
in <productname>Pgpool-II</productname> instances after
restart. (Muhammad Usama)
+ -->
+ <productname>Pgpool-II</productname> 再起動後、<productname>PostgreSQL</productname>
+ ノードのデータ不整合があったのでこれを修正しました。(bug 218) (Muhammad Usama)
</para>
<para>
- At the <productname>Pgpool-II</productname> startup, the
- status of each configured backend node is loaded from the
- backend status file or otherwise initialized by querying the
- backend nodes. This technique works fine in stand alone mode
- and also with the watchdog enabled as long as the status of
- backend nodes remains consistent until
- all <productname>Pgpool-II</productname> nodes got up and
- running. But since <productname>Pgpool-II</productname>
- does not sync the backend node status from the watchdog
- cluster at startup time, so in some cases
- the <productname>Pgpool-II</productname> nodes participating
- in the watchdog cluster may get a different status for the
- same backend, especially if
- the <productname>Pgpool-II</productname> nodes part of the
- watchdog cluster starts at different times and between that
- time an unavailable backend PostgreSQL node had become
- available again.
- </para>
- <para>
- So to solve this, the commit implements the new startup
- procedure for the
- standby <productname>Pgpool-II</productname>, And now the
- standby
- <productname>Pgpool-II</productname> will load the backend
- status of all
- configured <productname>PostgreSQL</productname> nodes from
- the watchdog master/coordinator node at the time of startup.
+ <!--
+ Watchdog does not synchronize status.
+ -->
+ watchdog がバックエンドノードを同期させなかったのが原因でした。
</para>
</listitem>
@@ -237,10 +322,12 @@
2016-09-06 [c0eb0ee] Enhance performance of SELECT when lots of rows involved.
-->
<para>
- Enhance performance of SELECT when lots of rows involved.
- (Tatsuo Ishii)
+ <!--
+ Enhance performance of SELECT when lots of rows involved. (Tatsuo Ishii)
+ -->
</para>
<para>
+ <!--
<productname>Pgpool-II</productname> flushes data to network
(calling write(2)) every time it sends a row data ("Data
Row" message) to frontend. For example, if 10,000 rows
@@ -250,16 +337,28 @@
enough to issue a write() with the command complete
message. Also there are unnecessary flushing are in handling
the command complete message.
+ -->
+ <productname>Pgpool-II</productname> がフロントエンドに行データを送るたび、
+ フラッシュするため、<function>write(2)</function> が呼び出されていました。
+ 例えば、10,000 行の場合、write(2)が10,000 回呼び出されます。この挙動のコストが高いです。
</para>
<para>
+ <!--
<ulink url="http://www.pgpool.net/pipermail/pgpool-hackers/2016-September/001784.html">Quick
testing</ulink> showed that from 47% to 62% performance
enhancements were achieved in some cases.
+ -->
+ <ulink url="http://www.pgpool.net/pipermail/pgpool-hackers/2016-September/001784.html">Quick testing</ulink>
+ のテスト結果から、この修正により、特定の場合で、性能向上ができたことがわかりました。
+ しかし、問い合わせが返す行が少ない場合は、まだ改善されていません。
</para>
<para>
+ <!--
Unfortunately, performance in workloads where transferring
few rows, will not be enhanced since such rows are needed to
flush to network anyway.
+ -->
+ しかし、問い合わせが返す行が少ない場合は、まだ改善されていません。
</para>
</listitem>
@@ -268,13 +367,20 @@
2016-08-26 [d768944] import PostgreSQL 9.6 parser
-->
<para>
+ <!--
Import <productname>PostgreSQL</productname> 9.6's SQL
parser. (Bo Peng)
+ -->
+ <productname>PostgreSQL</productname> 9.6's のパーサを取り込みました。 (Bo Peng)
</para>
<para>
+ <!--
This allows <productname>Pgpool-II</productname> to fully
understand the newly added SQL syntax such as <literal>COPY
INSERT RETURNING</literal>.
+ -->
+ これにより、<productname>Pgpool-II</productname> は <productname>PostgreSQL</productname>
+ 9.6 で導入された新しい構文 (<literal>COPY INSERT/UPDATE/DELETE ... RETURNING</literal> など) を理解可能です。
</para>
</listitem>
@@ -283,87 +389,11 @@
2016-08-26 [f284be4] Handling of pg_terminate_backend for simple query protocol
-->
<para>
+ <!--
In some cases pg_terminate_backend() now does not trigger a
fail-over. (Muhammad Usama)
- </para>
- <para>
- Since the pg_terminate_backend function
- in <productname>PostgreSQL</productname> is used to
- terminate the backend connection, So what happens is, when
- this function kills a <productname>PostgreSQL</productname>
- backend that is connected to
- the <productname>Pgpool-II</productname>, This disconnection
- of backend by pg_terminate_backend function is appeared as a
- backend node failure to
- the <productname>Pgpool-II</productname>. But the problem
- here is, PostgreSQL does not give any information to the
- client program that the connection is going to be killed
- because of the pg_terminate_backend call and on the client
- side, it looks similar to the backend node failure.
- </para>
- <para>
- Now to solve this in <productname>Pgpool-II</productname> we
- need two things. First is to identify the
- pg_terminate_backend function in the query and the
- <productname>Pgpool-II</productname> child process that
- hosts the particular backend connection which will be killed
- by that pg_terminate_backend function call, so that we get a
- heads up in advance about the backend termination, and
- secondly the routing of the query containing
- pg_terminate_backend also needs a new logic so that the
- query should be sent to the correct PostgreSQL node that
- hosts the backend with the PID referred by the
- pg_terminate_bakend()
- </para>
- <para>
- So how does this commit handles pg_terminate_backend()?? In
- the SimpleQuery() function which is the work horse of simple
- query processing in the <productname>Pgpool-II</productname>
- we start with the search of the pg_terminate_backend()
- function call in the query parse tree and if the search
- comes out to be successful, the next step is to locate
- the <productname>Pgpool-II</productname> child process and a
- backend node of that connection whose PID is specified in
- pg_terminate_backend function's argument. Once the
- connection and the <productname>Pgpool-II</productname>
- child process is identified, we just set the
- swallow_termination flag(added by this commit in
- ConnectionInfo structure) for that connection in the shared
- memory, and also set the query destination node to the
- backend node that hosts that particular connection and does
- not call pool_where_to_send() for this query so that the
- query should be sent to the correct backend node.
- </para>
- <para>
- Now when the query is routed to the correct node and
- consequently the backend gets killed, that results in the
- communication error on <productname>Pgpool-II</productname>
- side, the <productname>Pgpool-II</productname> already knows
- that this disconnection is due the pg_terminate_backend and
- not because of node failure as the swallow_termination flag
- is already set for the connection.
- </para>
- <para>
- Some works are still remaining.
- </para>
- <para>
- pg_terminate_backend is not handled with extended query
- protocol.
- </para>
- <para>
- Currently we only support
- pg_terminate_backend(constant number) function calls. If the
- expression or sub query is used in the argument of
- pg_terminate_backend then it would not be handled e.g
- <programlisting>
-pgpool=# select pg_terminate_backend(1025); -- Supported
-pgpool=# select pg_terminate_backend( 2 +1); -- NOT SUPPORTED
-pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
- </programlisting>
- </para>
- <para>
- Currently only one pg_terminate_backend call in a query is
- handled.
+ -->
+ ある場合では、pg_terminate_backend() 関数が failover を引き起さないようになりました。(Muhammad Usama)
</para>
</listitem>
@@ -386,7 +416,10 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
</sect2>
<sect2>
+ <!--
<title>Other Enhancements</title>
+ -->
+ <title>改善点</title>
<itemizedlist>
@@ -396,14 +429,22 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
-->
<para>
+ <!--
Make authentication error message more user friendly. (Tatsuo Ishii)
+ -->
+ 認証エラーメッセージがわかりやすくように改善されました。 (Tatsuo Ishii)
</para>
<para>
+ <!--
When attempt to connect to backend (including health
checking), emit error messages from backend something like
"sorry, too many clients already" instead of "invalid
authentication message response type, Expecting 'R' and
received '%c'"
+ -->
+ バックエンドに接続する時に(ヘルスチェックを含む)、
+ "invalid authentication message response type, Expecting 'R' and received '%c'" メッセージではなく
+ "sorry, too many clients already" メッセージが返されていました。
</para>
</listitem>
@@ -412,13 +453,10 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-08-22 [2088a17] Tighten up health check timer expired condition in pool_check_fd()
-->
<para>
+ <!--
Tighten up health check timer expired condition in pool_check_fd(). (Muhammad Usama)
- </para>
- <para>
- Check if the signal was actually the health check timer
- expire to make sure that we do not declare the timer expire
- due to some other signal arrived while waiting for data for
- health check in pool_check_fd().
+ -->
+ pool_check_fd()のヘルスチェックタイマーの期限切れ条件を強化しました。(Muhammad Usama)
</para>
</listitem>
@@ -428,13 +466,19 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-08-18 [d3211dc] Let watchdog_setup to be installed.
-->
<para>
+ <!--
Add new script called "watchdog_setup". (Tatstuo Ishii)
+ -->
+ 新しいスクリプト "watchdog_setup" が追加されました。 (Tatstuo Ishii)
</para>
<para>
+ <!--
<xref linkend="WATCHDOG-SETUP"> is a command to create a
temporary installation
of <productname>Pgpool-II</productname> clusters with
watchdog for mainly testings.
+ -->
+ <xref linkend="WATCHDOG-SETUP"> は watchdog 機能を有効にした Pgpool-II クラスタのテスト環境を構築するコマンドです。
</para>
</listitem>
@@ -444,15 +488,23 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-08-16 [d5c3cf2] Let pgpool_setup install into dist bin.
-->
<para>
+ <!--
Add "-pg" option to pgpool_setup. (Tatsuo Ishii)
+ -->
+ pgpool_setup に "pg" オプションが追加されました。(Tatsuo Ishii)
</para>
<para>
+ <!--
This is useful when you want to assign specific port numbers to
<productname>PostgreSQL</productname> while
using <xref linkend="PGPOOL-SETUP">. Also
now <command>pgpool_setup</command> is installed in the
standard bin directory which is same
as <command>pgpool</command>.
+ -->
+ <xref linkend="PGPOOL-SETUP"> を使用する時に、PostgreSQL に特定のポート番号を割り当てたい場合に便利です。
+ また、<command>pgpool</command> と同じように、
+ <command>pgpool_setup</command> が標準 bin ディレクトリにインストールされるようになりました。
</para>
</listitem>
@@ -461,13 +513,20 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-08-12 [9db83a8] Add "replication delay" column to "show pool_nodes".
-->
<para>
+ <!--
Add "replication delay" column to "show pool_nodes". (Tatsuo Ishii)
+ -->
+ <link linkend="SQL-SHOW-POOL-NODES">show pool_nodes</link> の出力結果に replication delay カラムが追加されました。(Tatsuo Ishii)
</para>
<para>
+ <!--
This column
shows the <link linkend="runtime-streaming-replication-check">
replication delay</link> value in bytes if operated in
streaming replication mode.
+ -->
+ streaming replication モードの場合、
+ このカラムは <link linkend="runtime-streaming-replication-check">replication delay</link> の値を bytes 単位で表示します。
</para>
</listitem>
@@ -476,15 +535,23 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-07-12 [726cb5d] Do not update status file if all backend nodes are in down status.
-->
<para>
+ <!--
Do not update status file if all backend nodes are in down status. (Chris Pacejo, Tatsuo Ishii)
+ -->
+ すべてのノードがダウンした場合、 status ファイルを更新しないように変更されました。(Chris Pacejo, Tatsuo Ishii)
</para>
<para>
+ <!--
This commit tries to remove the data inconsitency in
replication mode found
in <ulink url="http://www.pgpool.net/pipermail/pgpool-general/2015-August/003974.html">[pgpool-general:
3918]</ulink> by not recording the status file when all
backend nodes are in down status. This surprisingly simple
but smart solution was provided by Chris Pacejo.
+ -->
+ すべてのノードがダウンした場合、status ファイルに記録しないように、
+ <ulink url="http://www.pgpool.net/pipermail/pgpool-general/2015-August/003974.html">[pgpool-general:3918]</ulink> で
+ 報告されたデータの不整合を修正しました。Chris Pacejo により、シンプルかつスマートな解決方法が提供されました。
</para>
</listitem>
@@ -493,12 +560,19 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-05-23 [9342472] Permit pgpool to support multiple SSL cipher protocols
-->
<para>
- Allow to use multiple SSL cipher protocols. (Multiple Usama)
+ <!--
+ Allow to use multiple SSL cipher protocols. (Muhammad Usama)
+ -->
+ <productname>Pgpool-II</productname> が 複数 SSL cipher protocols に対応できるように修正しました。(Muhammad Usama)
</para>
<para>
+ <!--
By replacing TLSv1_method() with SSLv23_method() while
initializing the SSL session, we can use more protocols than
TLSv1 protocol.
+ -->
+ <function>SSLv23_method()</function> を使って SSLSession を初期化するように修正しました（PostgreSQL と同じように）。
+ この関数が特定バージョンのプロトコルを利用することではなく、互換性のあるプロトコルの最新バージョンを利用できるからです。
</para>
</listitem>
@@ -508,11 +582,18 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
of items in the black_function_list and white_function_list lists.
-->
<para>
+ <!--
Allow to use arbitrary number of items in the
black_function_list/white_function_list. (Muhammad Usama)
+ -->
+ black_function_list/white_function_list
+ に任意のアイテムの数が使用できるようになりました。(Muhammad Usama)
</para>
<para>
+ <!--
Previously there were fixed limits for those.
+ -->
+ これまで、このアイテムの数には上限がありました。
</para>
</listitem>
@@ -521,29 +602,46 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-02-17 [f2a5081] Properly process empty query (all comments)
-->
<para>
+ <!--
Properly process empty queries (all comments). (Tatsuo Ishii)
+ -->
+ コメントのみを含む空クエリを適切に処理できるよう修正しました。(Tatsuo Ishii)
</para>
<para>
+ <!--
<productname>Pgpool-II</productname> now recognizes an empty
query consisted of all comments (for example "/* DBD::Pg
ping test v3.5.3 */") (note that no ';') as an empty query.
+ -->
+ この修正で、Pgpool-II は "/* DBD::Pg ping test v3.5.3 */" (';' を含まないことに注意)
+ のような空クエリを正しく識別できるようになりました。
</para>
<para>
+ <!--
Before such that query was recognized an error.
+ -->
+ これまではエラークエリとして処理していました。
</para>
</listitem>
<listitem>
<!--
- 2016-02-01 [342471f] Add some warning messages for wd_authkey hash calculation failure
+ 2016-02-01 [44f43cc] Add some warning messages for wd_authkey hash calculation failure
-->
<para>
+ <!--
Add some warning messages for wd_authkey hash calculation failure. (Yugo Nagata)
+ -->
+ wd_authkey ハッシュ計算失敗時に警告メッセージを出力するようにしました。(Yugo Nagata)
</para>
<para>
+ <!--
Sometimes wd_authkey calculation fails for some reason other
than authkey mismatch. The additional messages make these
distinguishable for each other.
+ -->
+ たまに、認証キー不一致以外の何らかの理由で wd_authkey 計算に失敗することがあります。
+ メッセージ出力を追加することでこれらを互いに区別できるようにしました。
</para>
</listitem>
@@ -552,7 +650,10 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
</sect2>
<sect2>
+ <!--
<title>Changes</title>
+ -->
+ <title>変更点</title>
<itemizedlist>
@@ -561,12 +662,18 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-09-24 [cc33fe3] Change the default value of search_primary_node_timeout from 10 to 300.
-->
<para>
+ <!--
Change the default value of
<xref linkend="guc-search-primary-node-timeout"> from 10 to 300. (Tatstuo Ishii)
+ -->
+ <xref linkend="guc-search-primary-node-timeout"> のデフォルト値を 10 から 300 まで変更しました。(Tatstuo Ishii)
</para>
<para>
+ <!--
Prior default value 10 seconds is sometimes too short for a standby to
be promoted.
+ -->
+ これまで、デフォルト値 10s がスタンバイを昇格する際には小さすぎでした。
</para>
</listitem>
@@ -575,10 +682,17 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-06-09 [7671794] Change the Makefile under directory src/sql/,that is proposed by [pgpool-hackers: 1611]
-->
<para>
+ <!--
Change the <filename>Makefile</filename> under directory
<filename>src/sql/</filename>, that is proposed by
<ulink url="http://www.pgpool.net/pipermail/pgpool-hackers/2016-June/001611.html">
[pgpool-hackers: 1611]</ulink>. (Bo Peng)
+ -->
+ src/sql/ 配下の Makefile が修正されました。(Bo Peng)
+ </para>
+ <para>
+ 詳しくは <ulink url="http://www.pgpool.net/pipermail/pgpool-hackers/2016-June/001611.html">
+ [pgpool-hackers: 1611]</ulink> を参照してください。
</para>
</listitem>
@@ -587,12 +701,19 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-04-20 [883d761] Change the PID length of pcp_proc_count command output to 6 characters long
-->
<para>
+ <!--
Change the PID length of <link linkend="PCP-PROC-COUNT">pcp_proc_count</link> command output to 6 characters long. (Bo Peng)
+ -->
+ pcp_proc_count コマンドの出力結果のプロセス ID を 6 桁まで表示 できるよう修正しました。(Bo Peng)
</para>
<para>
+ <!--
If the <productname>Pgpool-II</productname> process ID are over 5 characters, the 6th character of each process ID
will be removed. This commit changes the process ID length of <link linkend="PCP-PROC-COUNT">pcp_proc_count</link> command
output to 6 characters long.
+ -->
+ 特定の環境において、pcp_proc_count コマンドの出力結果のプロセス ID が6 桁の場合、
+ 6 番目の文字が表示されませんでした。 この修正で、プロセス ID が最大 6 桁まで表示するよう変更しました。
</para>
</listitem>
<listitem>
@@ -600,20 +721,32 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-04-15 [9b62eca] Redirect all user queries to primary server
-->
<para>
+ <!--
Redirect all user queries to primary server. (Tatsuo Ishii)
+ -->
+ すべてのクエリがプライマリサーバに送信されるように変更しました。(Tatsuo Ishii)
</para>
<para>
+ <!--
Up to now some user queries are sent to other than the primary server
even if <xref linkend="guc-load-balance-mode"> = off. This commit changes the behavior: if
load_balance_mode = off in streaming replication mode, now all the
user queries are sent to the primary server only.
+ -->
+ レプリケーションモードにおける <xref linkend="guc-load-balance-mode"> = off の場合でも、
+ 一部のクエリがプライマリサーバ以外にも転送されていました。
+ この修正で、 streaming replication モードで load_balance_mode = off
+ の場合はすべてのクエリをプライマリサーバにのみ送るようにしました。
</para>
</listitem>
</itemizedlist>
</sect2>
<sect2>
+ <!--
<title>Bug fixes</title>
+ -->
+ <title>不具合修正</title>
<itemizedlist>
@@ -622,9 +755,13 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-09-27 [a7e459f] Fix the case when all backends are down then 1 node attached.
-->
<para>
+ <!--
Fix the case when all backends are down then 1 node attached. (Tatsuo Ishii)
+ -->
+ すべてのバックエンドがダウンした後に、1つのノードを復帰させる時の不具合が修正されました。(Tatsuo Ishii)
</para>
<para>
+ <!--
When all backends are down, no connection is accepted. Then 1
<productname>PostgreSQL</productname> becomes up, and attach the node using pcp_attach_node. It
successfully finishes. However, when a new connection arrives, still
@@ -633,6 +770,13 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
mode is streaming replication mode (native replication and other modes
are fine). Solution is, if all nodes are down, force to restart all
pgpool child.
+ -->
+ すべてのノードがダウンした後に、1つのノードが復元され、<command>pcp_attach_node</command>
+ コマンドでノートを復帰させます。コマンドが成功に実行されましたが、新しい接続が拒否されました。
+ <productname>Pgpool-II</productname> の子プロセスがキャッシュされた古い情報を参照したのが原因でした。
+ このキャッシュされた情報には、このノードの状態が down のままです。
+ この修正では、全ノードがダウンした場合、強制的に全 <productname>Pgpool-II</productname>
+ 子プロセスを再起動するようにしました。
</para>
</listitem>
<listitem>
@@ -640,9 +784,13 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-09-19 [e89e365] Fix for: [pgpool-general: 4997] Avoiding downtime when pgpool changes require a restart
-->
<para>
+ <!--
Fix for avoiding downtime when <productname>Pgpool-II</productname> changes require a restart. (Muhammad Usama)
+ -->
+ パラメータの設定を変更した後、<productname>Pgpool-II</productname>を再起動する際に発生するエラーが修正されました。(Muhammad Usama)
</para>
<para>
+ <!--
To fix this, The verification mechanism of configuration parameter values is
reversed, previously the standby nodes used to verify their parameter values
against the respective values on the master <productname>Pgpool-II</productname> node and when the
@@ -655,6 +803,10 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
join the watchdog cluster and the user has to manually look out for the
configuration inconsistency warnings in the master <productname>Pgpool-II</productname> log to avoid the
surprises at the time of <productname>Pgpool-II</productname> master switch over.
+ -->
+ 以前はスタンバイノードがマスターノードに対して設定パラメータの値を検証しましたが、
+ 今の修正で、マスターノードがスタンバイノードに対して設定パラメータの値を検証するようになりました。また、FATAL の代わりに WARNING が
+ 出力出力されるようになりました。そのため、設定が異なってもクラスタへの参加ができるようになりました。
</para>
</listitem>
<listitem>
@@ -662,25 +814,10 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-09-19 [233ae46] Fixing a problem with the watchdog failover_command locking mechanism
-->
<para>
+ <!--
Fix a problem with the watchdog <xref linkend="guc-failover-command"> locking mechanism. (Muhammad Usama)
- </para>
- <para>
- From <productname>Pgpool-II</productname> 3.5 watchdog was using the separate individual locks for each
- node-failover command (failover, failback and follow-master) and the lock was
- acquired just before executing the respective failover script and was released
- as soon as the script execution finishes. This technique although was very
- efficient but also had a problem. If the <xref linkend="guc-failover-command"> takes a very little
- time and gets finished before the lock request from other <productname>Pgpool-II</productname> node
- arrives, the other node is also granted a lock, since the lock was already
- released by the first node at that time. Consequently, both nodes ends up
- executing the failover script.
- So to fix this we are reverting back to the tested failover interlocking design
- used prior to <productname>Pgpool-II</productname> 3.5 where all the commands gets locked at the failover
- start by the node that becomes a lock-holder and each command lock is released
- after its execution finishes. And only the lock-holder node is allowed to
- acquire/release the individual command lock. That way the lock-holder node
- keeps the lock-holder status throughout the span of the failover execution and
- the system becomes less time sensitive.
+ -->
+ watchdog が有効な場合、<xref linkend="guc-failover-command"> コマンドのロック取得時の処理が改善されました。(Muhammad Usama)
</para>
</listitem>
<listitem>
@@ -688,15 +825,11 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-09-12 [b412da2] Disable strict aliasing optimization.
-->
<para>
- Disable strict aliasing optimization. (Tatsuo Ishii)
- </para>
- <para>
- <function>flatten_set_variable_args()</function> was imported from <productname>PostgreSQL</productname>
- in <productname>Pgpool-II</productname>
- 3.5. To make the code work, a compiler flag <option>-fno-strict-aliasing</option> is
- necessary (<productname>PostgreSQL</productname> does so). Unfortunately when the function was
- imported, the compiler flag was not added. To fix this, <filename>configure.ac</filename>
- was modified.
+ <!--
+ Add compiler flag "-fno-strict-aliasing" in <filename>configure.ac</filename> to fix compiler error. (Tatsuo Ishii)
+ -->
+ コンパイルエラーを修正するために、<filename>configure.ac</filename>
+ ファイルにコンパイルフラグ "-fno-strict-aliasing" が追加されました。(Tatsuo Ishii)
</para>
</listitem>
<listitem>
@@ -704,13 +837,19 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-09-09 [650c660] Do not use random() while generating MD5 salt.
-->
<para>
+ <!--
Do not use <function>random()</function> while generating MD5 salt. (Tatsuo Ishii)
+ -->
+ MD5 salt を生成するときに、<function>random()</function> を使用しないように修正しました。(Tatsuo Ishii)
</para>
<para>
+ <!--
<function>random()</function> should not be used in security related applications. To
- replace <function>random()</function>, import <function>PostmasterRandom()</function> from PostgreSQL. Also
- store current time at the start up of <productname>Pgpool-II</productname> main process for later
- use.
+ replace <function>random()</function>, import <function>PostmasterRandom()</function> from PostgreSQL.
+ -->
+ <function>random()</function> 関数がセキュリティ関連のアプリケーションに使用しないべきなので、
+ <function>random()</function> の代わりに <productname>PostgreSQL</productname> の
+ <function>PostmasterRandom()</function> 使用するように変更しました。
</para>
</listitem>
@@ -719,16 +858,10 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-09-05 [455df3d] Don't ignore sync message from frontend when query cache is enabled.
-->
<para>
+ <!--
Don't ignore sync message from frontend when query cache is enabled. (Tatsuo Ishii)
- </para>
- <para>
- While returning cached query result, sync message sent from frontend
- is discarded. This is harmless because "ready for query" messages is
- sent to frontend afterward. Problem is, AccessShareLock held by
- previous parse message processing is not released until sync message
- is received by the backend. Fix is, forwarding the sync message to
- backend and discarding "ready for query" message returned from
- backend.
+ -->
+ クエリキャッシュが有効な場合、sync メッセージが廃棄されないよう修正しました。(Tatsuo Ishii)
</para>
</listitem>
<listitem>
@@ -736,11 +869,17 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-08-29 [4c23c9b] Fix for 237: Pgpool-II fails to start if listen_addresses is empty string
-->
<para>
+ <!--
Fix bug that <productname>Pgpool-II</productname> fails to start if <xref linkend="guc-listen-addresses"> is empty string. (bug 237) (Muhammad Usama)
+ -->
+ listen_addresses が空の場合、Pgpool-II が起動できない不具合を修正しました。(bug 237) (Muhammad Usama)
</para>
<para>
+ <!--
The socket descriptor array (fds[]) was not getting the array end marker
when TCP listen addresses are not used.
+ -->
+ TCP listen addresses が空の場合、socket descriptor 配列（fds[]）の終了マークがないのが原因でした。
</para>
</listitem>
<listitem>
@@ -748,7 +887,10 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-08-22 [879d16a] Create regression log directory if it does not exist yet.
-->
<para>
+ <!--
Create regression log directory if it does not exist yet. (Tatsuo Ishii)
+ -->
+ レグレッションログディレクトリが存在しない場合、作成されるようになりました。(Tatsuo Ishii)
</para>
</listitem>
<listitem>
@@ -756,14 +898,10 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-08-17 [37e376e] Fixing the error messages when the socket operation fails
-->
<para>
+ <!--
Fixing the error messages when the socket operation fails. (Muhammad Usama)
- </para>
- <para>
- When some socket operation fails, we issue close socket before throwing an
- error which causes the errno value to be overwritten and consequently the error
- log does not print the correct failure reason.
- The solution is to save the errno before closing the socket and use the saved
- value to print error description.
+ -->
+ ソケットの操作に失敗したときのエラーメッセージを修正しました。(Muhammad Usama)
</para>
</listitem>
<listitem>
@@ -771,12 +909,11 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-08-15 [f2b5d17] Fix regression failure of 003.failover.
-->
<para>
- Fix regression failure of 003.failover. (Tatsuo Ishii)
- </para>
- <para>
- Update expected data to reflect the changes made to <link linkend="SQL-SHOW-POOL-NODES">show pool_nodes</link>.
- Also fix <link linkend="SQL-SHOW-POOL-NODES">show pool_nodes</link> to proper use "_" instead of space for the
- column name.
+ <!--
+ Update regression test 003.failover to reflect the changes made to
+ <link linkend="SQL-SHOW-POOL-NODES">show pool_nodes</link>. (Tatsuo Ishii)
+ -->
+ <link linkend="SQL-SHOW-POOL-NODES">show pool_nodes</link> コマンドの修正を反映し、レグレッションテスト 003.failover を変更しました。
</para>
</listitem>
<listitem>
@@ -784,14 +921,10 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-08-09 [a7bc4c8] Fix hang when portal suspend received
-->
<para>
+ <!--
Fix hang when portal suspend received. (bug 230) (Tatsuo Ishii)
- </para>
- <para>
- When portal suspend message is received, it's not enough to forward it
- to the client. Since backend expects to receive execute message,
- trying to read further more messages from backend will never
- succeed. To fix this, turn off the query in progress flag, which will
- pole incoming message from the client.
+ -->
+ Portal suspend を受け取ったときのハングが修正されました。(bug 230) (Tatsuo Ishii)
</para>
</listitem>
<listitem>
@@ -811,43 +944,20 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-08-02 [9b122ab] SIGUSR1 signal handler should be installed before watchdog initialization.
-->
<para>
+ <!--
SIGUSR1 signal handler should be installed before watchdog initialization. (Muhammad Usama)
+ -->
+ SIGUSR1 シグナルハンドラーを watchdog の初期化前にインストールするように修正しました。(Muhammad Usama)
</para>
<para>
+ <!--
Since there can be a case where a failover request from other watchdog nodes
arrive at the same time when the watchdog has just been initialized,
and if we wait any longer to install a SIGUSR1 signal handler, it can
result in a potential crash
- </para>
- </listitem>
- <listitem>
- <!--
- 2016-08-02 [bda946e]Fix for 218: Inconsistent status of Postgresql nodes in pgPool instances
- after restart. Watchdog not syncing status.
-->
- <para>
- Fix for bug of inconsistent status of <productname>PostgreSQL</productname> nodes in <productname>Pgpool-II</productname> instances
- after restart. (bug 218) (Muhammad Usama)
- </para>
- <para>
- Watchdog does not synchronize status.
- Currently at the <productname>Pgpool-II</productname> startup, The status of each configured backend node
- is loaded from the backend status file or otherwise initialized by querying the
- backend nodes. This technique works fine in stand alone mode and also with
- the watchdog enabled as long as the status of backend nodes remains consistent
- until all <productname>Pgpool-II</productname> nodes got up and running.
- But since <productname>Pgpool-II</productname> does not sync the backend node status from the
- watchdog cluster at startup time, so in some cases the pgpool-II nodes
- participating in the watchdog cluster may get a different status for the same
- backend, especially if the <productname>Pgpool-II</productname> nodes part of the watchdog cluster starts
- at different times and between that time an unavailable backend <productname>PostgreSQL</productname> node
- had become available again.
- </para>
- <para>
- So to solve this, the commit implements the new startup procedure for the
- standby <productname>Pgpool-II</productname>, And now the standby <productname>Pgpool-II</productname> will load the backend status of
- all configured <productname>PostgreSQL</productname> nodes from the watchdog master/coordinator node
- at the time of startup.
+ watchdog 初期化直後に 他のwatchdog ノードから failover リクエストがあった場合、
+ SIGUSR1 シグナルハンドラーのインストールを待っていれば、クラッシュが発生する可能性がありました。
</para>
</listitem>
<listitem>
@@ -855,12 +965,21 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-08-01 [024eaea] Fix for 215: pgpool doesnt escalate ip in case of another node inavailability
-->
<para>
+ <!--
Fix <productname>Pgpool-II</productname> doesn't escalate ip in case of another node inavailability. (bug 215) (Muhammad Usama)
+ -->
+ 他のノードが利用できない場合、<productname>Pgpool-II</productname> が
+ IPアドレスをエスカレートしない不具合を修正しました。(bug 215) (Muhammad Usama)
</para>
<para>
+ <!--
The heartbeat receiver fails to identify the heartbeat sender watchdog node when
the heartbeat destination is specified in terms of an IP address while
wd_hostname is configured as a hostname string or vice versa.
+ -->
+ Heartbeat destination が IPアドレスで指定され、wd_hostname が hostname で設定される場合、
+ heartbeat receiver が heartbeat sender watchdog ノードを識別できなかったのが原因でした。
+ 逆の場合でも同様なエラーが起こります。
</para>
</listitem>
<listitem>
@@ -868,15 +987,25 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-07-29 [5bce300] Fixing a coding mistake in watchdog code.
-->
<para>
+ <!--
Fixing a coding mistake in watchdog code. (Muhammad Usama)
+ -->
+ watchdog に関するコーデイングミスを修正しました。(Muhammad Usama)
</para>
<para>
+ <!--
<function>wd_issue_failover_lock_command()</function> function is supposed to forward command type
passed in as an argument to the <function>wd_send_failover_sync_command()</function> function instead
it was passing the NODE_FAILBACK_CMD command type.
+ -->
+ <function>wd_issue_failover_lock_command()</function> 関数が <function>wd_send_failover_sync_command()</function>
+ 関数に NODE_FAILBACK_CMD ではなく、渡してきたコマンドタイプを引数として渡すように修正しました。
</para>
<para>
+ <!--
The commit also contains some log message enhancements.
+ -->
+ この修正で、いくつかのログメッセージも改善しました。
</para>
</listitem>
<listitem>
@@ -896,13 +1025,22 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-07-27 [3cbce4e] Replace "MAJOR" macro to prevent occasional failure.
-->
<para>
+ <!--
Replace "MAJOR" macro to prevent occasional failure. (Tatsuo Ishii)
+ -->
+ 「MAJOR」マクロによる発生しうるセグメンテーションフォルトを修正しました。(Tatsuo Ishii)
</para>
<para>
+ <!--
The macro calls <function>pool_virtual_master_db_node_id()</function> and then access
backend->slots[id]->con using the node id returned. In rare cases, it
could point to 0 (in case when the DB node is not connected), which
gives access to con->major, then it causes a segfault.
+ -->
+ MAJOR が <function>pool_virtual_master_db_node_id()</function> を呼出し、
+ 戻り値 idを使ってbackend->slots[id]->con にアクセスします。
+ DB にアクセスできない場合(ほとんど発生しない)、con->major にアクセスし、
+ メンテーションフォルトを引き起す可能性がありました。
</para>
</listitem>
<listitem>
@@ -910,14 +1048,24 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-07-14 [866575c] Fix for [pgpool-hackers: 1501] kind does not match error
-->
<para>
+ <!--
Fix "kind mismatch" error message in <productname>Pgpool-II</productname>. (Muhammad Usama)
+ -->
+ "kind mismatch" エラーメッセージの処理について修正しました。(Muhammad Usama)
</para>
<para>
+ <!--
Many of "kind mismatch..." errors are caused by notice/warning
messages produced by one or more of the DB nodes. In this case now
<productname>Pgpool-II</productname> forwards the messages to frontend, rather than throwing the
"kind mismatch..." error. This would reduce the chance of "kind
mismatch..." errors.
+ -->
+ 多くの"kind mismatch..."エラーは、NOTICE や WARNING メッセージが
+ DBノードのいくつかで起こることによるものです。
+ この修正では、そうしたケースにおいて、"kind mismatch..."エラーを引き起こすのではなく、
+ NOTICE や WARNINGメッセージをフロントエンドに送るようになりました。
+ これにより、"kind mismatch..."エラーの発生が減少します。
</para>
</listitem>
<listitem>
@@ -925,7 +1073,10 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-07-14 [680e329] Fix handling of pcp_listen_addresses config parameter.
-->
<para>
+ <!--
Fix handling of <xref linkend="guc-pcp-listen-addresses"> config parameter. (Muhammad Usama)
+ -->
+ <xref linkend="guc-pcp-listen-addresses"> パラメータの処理の不具合を修正しました。(Muhammad Usama)
</para>
</listitem>
<listitem>
@@ -933,7 +1084,10 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-07-07 [e245587] Save and restore errno in each signal handler.
-->
<para>
+ <!--
Save and restore errno in each signal handler. (Tatsuo Ishii)
+ -->
+ シグナルハンドラ中でエラー番号が保存されるようになりました。 (Tatsuo Ishii)
</para>
</listitem>
<listitem>
@@ -942,15 +1096,20 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-07-07 [0d1cdf9] Fix usage of wait(2) in pgpool main process
-->
<para>
+ <!--
Fix usage of <function>wait(2)</function> in pgpool main process. (Tatsuo Ishii)
+ -->
+ pgpool メインプロセスの <function>wait(2)</function> の扱いを修正しました。(Tatsuo Ishii)
</para>
<para>
- When child process dies, SIGCHLD signal is raised and <function>wait(2)</function> knows
- the event. However, multiple child death does not necessarily creates
- exact same number of SIGCHLD signal as the number of dead children and
- <function>wait(2)</function> could wait for an event which never happens in this case. I
- Actually encountered this situation while testing <productname>Pgpool-II</productname>. Solution
- is, to use <function>waitpid(2)</function> instead of <function>wait(2)</function>.
+ <!--
+ The usage of <function>wait(2)</function> in <productname>Pgpool-II</productname>
+ main could cause infinite wait in the system call. Solution is,
+ to use <function>waitpid(2)</function> instead of <function>wait(2)</function>.
+ -->
+ システムコールで <productname>Pgpool-II</productname> メインプロセスの
+ <function>wait(2)</function> が無限ループを引き起こす可能性があります。
+ この修正で、 <function>wait(2)</function> の代わりに、<function>waitpid(2)</function> を使うように変更しました。
</para>
</listitem>
<listitem>
@@ -958,13 +1117,12 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-06-28 [bb41a1e] Fix confusing error messages.
-->
<para>
+ <!--
Fix confusing error messages. (Tatsuo Ishii)
- </para>
- <para>
- <function>pool_read()</function> does not emit error messages when <function>read(2)</function> returns -1 if
- <xref linkend="guc-fail-over-on-backend-error"> is off. In any case the cause of error
- should be emitted. I do not back port this because it's a too trivial
- enhancement.
+ -->
+ <xref linkend="guc-fail-over-on-backend-error"> が off の場合、
+ <function>read(2)</function> が -1 を返しても
+ <function>pool_read()</function> がエラーメッセージを発行しない不具合が修正されました。(Tatsuo Ishii)
</para>
</listitem>
<listitem>
@@ -972,13 +1130,18 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-06-24 [a01624f] Fix buffer over run problem in "show pool_nodes".
-->
<para>
+ <!--
Fix buffer over run problem in "show pool_nodes". (Tatsuo Ishii)
+ -->
+ <command>show pool_nodes</command> でのバッファオーバーランを修正しました。(Tatsuo Ishii)
</para>
<para>
+ <!--
While processing "show pool_nodes", the buffer for hostname was too
short. It should be same size as the buffer used for <filename>pgpool.conf</filename>.
- Problem reported by a twitter user who is using pgpool on AWS (which
- could have very long hostname).
+ -->
+ <command>show pool_nodes</command> を実行時、hostname に割り当てられたバッファが十分ではないのが原因でした。
+ <filename>pgpool.conf</filename> のバッファサイズと同じようにしました。
</para>
</listitem>
<listitem>
@@ -986,12 +1149,20 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-06-17 [4c63d10] Fixing [pgpool-hackers: 1638] pgpool-II does not use default configuration
-->
<para>
+ <!--
Fix <ulink url="http://www.pgpool.net/pipermail/pgpool-hackers/2016-June/001638.html">
[pgpool-hackers: 1638]</ulink> pgpool-II does not use default configuration. (Muhammad Usama)
+ -->
+ <ulink url="http://www.pgpool.net/pipermail/pgpool-hackers/2016-June/001638.html">
+ [pgpool-hackers: 1638]</ulink> で報告された、<productname>Pgpool-II</productname>
+ がデフォルトの設定を使用しない不具合が修正されました。(Muhammad Usama)
</para>
<para>
+ <!--
Configuration file not found should just throw a WARNING message
instead of ERROR or FATAL.
+ -->
+ 設定ファイルが見つからない場合は、 ERROR または FATAL ではなく、WARNING を返すように修正しました。
</para>
</listitem>
<listitem>
@@ -999,29 +1170,52 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-06-15 [226a21b] Fix bug with load balance node id info on shmem
-->
<para>
+ <!--
Fix bug with load balance node id info on shmem. (Tatsuo Ishii)
+ -->
+ 共有メモリ上のロードバランスノードの書き込みに関するバグを修正しました。(Tatsuo Ishii)
</para>
<para>
+ <!--
There are few places where the load balance node was mistakenly put on
wrong place. It should be placed on:
+ -->
+ 領域が少ないため、ロードバランスノードは間違ったことろに置かれてしまいました。
+ </para>
+ <para>
+ [正しい場所]
+ </para>
<programlisting>
ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancing_node].
</programlisting>
+ <!--
In fact it was placed on:
+ -->
+ <para>
+ [実際に置かれた場所]
+ </para>
<programlisting>
*con_info[child id, connection pool_id, 0].load_balancing_node].
</programlisting>
- </para>
<para>
+ <!--
As long as the backend id in question is 0, it is ok. However while
testing <productname>Pgpool-II</productname> 3.6's enhancement regarding failover, if primary
node is 1 (which is the load balance node) and standby is 0, a client
connecting to node 1 is disconnected when failover happens on node
0. This is unexpected and the bug was revealed.
+ -->
+ バックエンド id が 0 の場合、上記バグが発生しませんが、
+ <productname>Pgpool-II</productname> 3.6 のフェイルオーバーテストで、
+ プライマリノードが 1 (ロードバランスノード)、スタンバイノードが 0 の場合、
+ ノード1 の接続が切断され、フェイルオーバーが起きています。これは想定外のバグです。
</para>
<para>
+ <!--
It seems the bug was there since long time ago but it had not found
until today by the reason above.
+ -->
+ このバグが前からありましたが、上記の原因で、今まで見つかっておリませんでした。
</para>
</listitem>
<listitem>
@@ -1029,12 +1223,20 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
2016-06-09 [6ae42e7] fix for 0000197: pgpool hangs connections to database.
-->
<para>
+ <!--
Fix for bug that pgpool hangs connections to database. (bug 197) (Muhammad Usama)
+ -->
+ #197 で報告されたハングを修正しました。(bug 197) (Muhammad Usama)
</para>
<para>
+ <!--
The client connection was getting stuck when backend node and remote <productname>Pgpool-II</productname>
node becomes unavailable at the same time. The reason was a missing command
timeout handling in the function that sends the IPC commands to watchdog.
+ -->
+ watchdog が有効で、バックエンドノードとリモート <productname>Pgpool-II</productname>
+ ノードが同時接続できなくになった場合、クライアント接続がスタックします。
+ 原因は watchdog に IPC コマンドを送信する関数を呼び出すコマンドタイムアウトがなかったからです。
</para>
</listitem>
<listitem>
@@ -1042,13 +1244,22 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
2016-06-08 [294cf4a] Fix a posible hang during health checking
-->
<para>
+ <!--
Fix a posible hang during health checking. (bug 204) (Yugo Nagata)
+ -->
+ ヘルスチェックで発生し得るハングアップを修正しました。(bug 204) (Yugo Nagata)
</para>
<para>
+ <!--
Helath checking was hang when any data wasn't sent
from backend after <function>connect(2)</function> succeeded. To fix this,
<function>pool_check_fd()</function> returns 1 when <function>select(2)</function> exits with
EINTR due to SIGALRM while health checkking is performed.
+ -->
+ <function>connect(2)</function> が成功し、
+ その後バックエンドからデータが送信されない場合、ヘルスチェックがハングしていました。
+ ヘルスチェックが行われると、<function>select(2)</function> に SIGALRM を送信し、
+ EINTR で抜けて、<function>pool_check_fd()</function> は 1 を返すように修正しました。
</para>
</listitem>
<listitem>
@@ -1056,10 +1267,13 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
2016-05-25 [a2d04ab] Deal with the case when the primary is not node 0 in streaming replication mode.
-->
<para>
+ <!--
Deal with the case when the primary is not node 0 in streaming replication mode. (Tatsuo Ishii)
+ -->
+ streaming replication モードで、プライマリノードが 0 ではない場合に発生する不具合が修正されました。 (Tatsuo Ishii)
</para>
<para>
-
+ <!--
<ulink url="http://www.pgpool.net/mantisbt/view.php?id=194#c837">
http://www.pgpool.net/mantisbt/view.php?id=194#c837</ulink> reported that if
primary is not node 0, then statement timeout could occur even after
@@ -1068,24 +1282,28 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
node, which was not supposed to happen, thus <function>do_query()</function> sends queries
to wrong node (this is not clear from the report but I confirmed it in
my investigation).
+ -->
+ http://www.pgpool.net/mantisbt/view.php?id=194#c837の報告により、
+ bug194-3.3.diff を適用しても、プライマリノードが 0 ではない場合、
+ ステートメントタイムアウトが発生する可能性がありました。
+ 調査した結果、MASTER マクロがプライマリノードまたはロードバランスノード
+ 以外のノードを返したからです。そのため、<function>do_query()</function>
+ がクエリを間違った ノードに送信してしまいました（これは報告で確認されていませんが、 調査で確認できました）。
</para>
<para>
+ <!--
<function>pool_virtual_master_db_node_id()</function>, which is called in MASTER macro
returns query_context->virtual_master_node_id if query context
exists. This could return wrong node if the variable has not been set
yet. To fix this, the function is modified: if the variable is not
either load balance node or primary node, the primary node id is
returned.
- </para>
- <para>
- For master and 3.5-stable, additional fixes/enhancements are made:
- <function>pool_extended_send_and_wait()</function> now issues flush message if the request
- is 'E' (execute). Before it was issued outside (in Execute), but this
- makes the logic to determine to which node the flush message to be
- sent unnecessary complex.
- </para>
- <para>
- A debug message in pool_write is enhanced by adding backend node id.
+ -->
+ MASTER マクロと呼ばれる <function>pool_virtual_master_db_node_id()</function> が、
+ クエリコンテキストが存在する場合、query_context->virtual_master_node_id を返します。
+ その変数が初期化されていない場合、この関数が間違ったノード を返す可能性があります。
+ そのため、<function>pool_virtual_master_db_node_id()</function> 関数を以下のように修正しました。
+ 戻り値がプライマリノードまたはロード バランスノードではない場合、プライマリノードを返します。
</para>
</listitem>
<listitem>
@@ -1093,18 +1311,38 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
2016-05-24 [69d3fae] If statement timeout is enabled on backend and do_query() sends a
-->
<para>
- If statement timeout is enabled on backend and <function>do_query()</function> sends a query to primary node, and all of following user queries are sent to
+ <!--
+ If statement timeout is enabled on backend and <function>do_query()</function>
+ sends a query to primary node, and all of following user queries are sent to
standby, it is possible that the next command, for example END, could
cause a statement timeout error on the primary, and a kind mismatch
error on pgpool-II is raised. (bug 194) (Tatsuo Ishii)
+ -->
+ バックエンドのステートメントタイムアウトが有効な場合、
+ <function>do_query()</function> が最初のクエリをプライマリノードに送信し、
+ それ以降のユーザクエリをスタンバイノードに送信します。
+ 例えば、END コマンドの場合、プライマリノードのステートメントタイムアウトを引き起こし、
+ kind mismatch error が発生する可能性がありました。(bug 194) (Tatsuo Ishii)
</para>
<para>
+ <!--
This fix tries to mitigate the problem by sending sync message instead
of flush message in <function>do_query()</function>, expecting that the sync message reset
the statement timeout timer if we are in an explicit transaction. We
cannot use this technique for implicit transaction case, because the
sync message removes the unnamed portal if there's any.
+ Plus, pg_stat_statement will no longer show the query issued by
+ do_query() as "running".
+ -->
+ この問題を軽減するために、<function>do_query()</function>
+ がフラッシュメッセージを送信する代わりに、sync メッセージ送信するように修正しました。
+ sync メッセージを送信することで、明示的トランザクションの場合、
+ ステートメントタイムアウトタイマーがリセットされます。
+ unnamed portal が存在する場合、sync メッセージが unnamed portal を削除しますので、
+ 暗黙的トランザクションの場合には適用しません。
+
+ また、pg_stat_statement が <function>do_query()</function> が発行したクエリを "running" で表示しなくなります。
</para>
<para>
Plus, pg_stat_statement will no longer show the query issued by
@@ -1116,12 +1354,20 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
2016-05-22 [0c0e727] Fix extended protocol handling in raw mode
-->
<para>
+ <!--
Fix extended protocol handling in raw mode. (Tatsuo Ishii)
+ -->
+ 拡張プロトコルのraw モードでのバグを修正しました。(bug 152) (Tatsuo Ishii)
</para>
<para>
+ <!--
Bug152 reveals that extended protocol handling in raw mode (actually
other than in stream mode) was wrong in <function>Describe(</function>) and <function>Close()</function>.
Unlike stream mode, they should wait for backend response.
+ -->
+ Bug 152の報告により、拡張プロトコルの raw モード（実は stream モード以外）で
+ <function>Describe()</function> と <function>Close()</function>
+ の処理に誤りがありました。stream モードとは異なり、バックエンドからの応答を待つべきでした。
</para>
</listitem>
<listitem>
@@ -1129,7 +1375,10 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
2016-05-20 [78c5d56] Fix confusing comments in pgpool.conf
-->
<para>
+ <!--
Fix confusing comments in <filename>pgpool.conf</filename>. (Tatsuo Ishii)
+ -->
+ <filename>pgpool.conf</filename> の不正確なコメントを修正しました。(Tatsuo Ishii)
</para>
</listitem>
<listitem>
@@ -1137,10 +1386,16 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
2016-05-11 [de905f6] Fix documetation bug about raw mode
-->
<para>
+ <!--
Fix Japanese and Chinese documetation bug about raw mode. (Yugo Nagata, Bo Peng)
+ -->
+ ドキュメントのraw モードに関する内容の誤りを修正しました。(Yugo Nagata, Bo Peng)
</para>
<para>
+ <!--
Connection pool is avalilable in raw mode.
+ -->
+ raw モードの場合、コネクションプーリングが有効です。
</para>
</listitem>
<listitem>
@@ -1149,15 +1404,25 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
SET default_transaction_isolation TO 'serializable'.
-->
<para>
+ <!--
Fix is_<function>set_transaction_serializable()</function> when
SET default_transaction_isolation TO 'serializable'. (bug 191) (Bo Peng)
+ -->
+ <function>is_set_transaction_serializable()</function> 関数の
+ <command>SET default_transaction_isolation TO 'serializable'</command> のバグを修正しました。(bug 191) (Bo Peng)
</para>
<para>
+ <!--
SET default_transaction_isolation TO 'serializable' is sent to
not only primary but also to standby server in streaming replication mode,
and this causes an error. Fix is, in streaming replication mode,
SET default_transaction_isolation TO 'serializable' is sent only to the
primary server.
+ -->
+ <productname>Pgpool-II</productname> は <command>SET default_transaction_isolation TO 'serializable'</command>
+ をプライマリだけではなく、スタンバイにも送信してしまい、エラーが起きていました。
+ この修正で、streaming replication モードの場合、<command>SET default_transaction_isolation TO 'serializable'</command>
+ がプライマリサーバのみに送信されます。
</para>
</listitem>
<listitem>
@@ -1165,9 +1430,13 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
2016-04-13 [a5fdf78] Fix extended protocol hang with empty query
-->
<para>
- Fix extended protocol hang with empty query. (bug 190 (Tatsuo Ishii))
+ <!--
+ Fix extended protocol hang with empty query. (bug 190) (Tatsuo Ishii)
+ -->
+ 拡張プロトコルにおける空クエリの場合、発生し得るハングアップを修正しました。(Tatsuo Ishii)
</para>
<para>
+ <!--
The fixes related to extended protocol cases in 3.5.1 broke the case
of empty query. In this case backend replies with "empty query
response" which is same meaning as a command complete message. Problem
@@ -1177,6 +1446,11 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
sync message. Fix is, resetting the in progress flag after receiving
the empty query response and reads from frontend expecting it sends a
sync message.
+ -->
+ <productname>Pgpool-II</productname> は空のクエリの応答に対して、
+ クエリ進行中フラグをリセットせず、 バックエンドの応答を待ち続けることが原因でした。
+ この修正では、空のクエリの応答を得た場合、<productname>Pgpool-II</productname>
+ はクエリ進行中フラグをリセットし、 フロントエンドから Sync メッセージを受信するように修正しました。
</para>
</listitem>
<listitem>
@@ -1184,48 +1458,47 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
2016-04-05 [64696fd] Fix for [pgpool-general: 4569] PGPoolII-3.5 : segfault
-->
<para>
+ <!--
Fix for <ulink url="http://www.pgpool.net/pipermail/pgpool-general/2016-March/004627.html">
- [pgpool-general: 4569]</ulink> <productname>Pgpool-II</productname> 3.5 : segfault
+ [pgpool-general: 4569]</ulink> segfault during trusted_servers check. (Muhammad Usama)
+ -->
+ <ulink url="http://www.pgpool.net/pipermail/pgpool-general/2016-March/004627.html">
+ [pgpool-general: 4569]</ulink> により報告された
+ trusted_servers チェック時のセグメンテーションフォルトを修正しました。 (Muhammad Usama)
</para>
<para>
+ <!--
PostgreSQL's memory and exception manager APIs adopted by the <productname>Pgpool-II</productname> 3.4 are not
thread safe and are causing the segmentation fault in the watchdog lifecheck
process, as it uses the threads to ping configured trusted hosts for checking
the upstream connections.
Fix is to remove threads and use the child process approach instead.
+ -->
+ <productname>Pgpool-II</productname> 3.4 からは <productname>PostgreSQL</productname>
+ のメモリマネージャおよび 例外マネージャ API を流用していますが、
+ それはスレッドセーフ ではありません。上位接続を確認するため ping の応答で信頼できるサーバ確認時、
+ watchdog lifecheck プロセスでセグメンテ ーションフォルトを引き起こしていました。
+ スレッドを削除し、 子プロセスを使うように修正しました。
</para>
</listitem>
<listitem>
<!--
- 2016-05-29 [f7723c8] Validating the PCP packet length
+ 2016-03-29 [f7723c8] Validating the PCP packet length
-->
<para>
+ <!--
Validating the PCP packet length. (Muhammad Usama)
+ -->
+ PCP パケットの長さを検証するよう修正されました。(Muhammad Usama)
</para>
<para>
+ <!--
Without the validation check, a malformed PCP packet can crash the PCP child
and/or can run the server out of memory by sending the packet with a
very large data size.
- </para>
- </listitem>
- <listitem>
- <!--
- 2016-03-28 [f305fbe] Fix pgpool hang bug (deal with bug 167)
-->
- <para>
- Fix <productname>Pgpool-II</productname> hang bug (bug 167). (Tatsuo Ishii)
- </para>
- <para>
- <productname>Pgpool-II</productname> 3.5 or after in streaming replication mode does not wait for
- response from each phase such parse, bind anymore. However, if
- do_query is called, it sends flush message to retrieve the result of
- system catalog look up. This is only sent to primary node which may
- results in retrieving previous message results, for example parse
- complete. If standby is assigned to load balance node, the node does
- not return parse complete message, which will cause a problem in
- bug167 case, because parse message for "BEGIN" was sent to both the
- primary and the standby. Fix is, send flush message in do_query if the
- load balance node is one of standbys.
+ この検証がない場合、非常に巨大なデータサイズのパケットを送信することで、
+ 不正な PCP パケットが PCP 子プロセスをクラッシュさせたり、サーバで out of memory を発生させることが可能でした。
</para>
</listitem>
<listitem>
@@ -1233,18 +1506,34 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
2016-03-26 [d1c03f2] Fix pgpool_setup to not confuse log output
-->
<para>
+ <!--
Fix <link linkend="PGPOOL-SETUP">pgpool_setup </link> to not confuse log output. (Tatsuo Ishii)
+ -->
+ <link linkend="PGPOOL-SETUP">pgpool_setup </link> のログ出力の異常を修正しました。(Tatsuo Ishii)
</para>
<para>
+ <!--
Before it simply redirects the stdout and stderr of pgpool process to
a log file. This could cause log contents being garbled or even
missed because of race condition caused by multiple process being
- writing concurrently. I and Usama found this while investigating the
- regression failure of 004.watchdog.
+ writing concurrently.
+ -->
+ 以前は <productname>Pgpool-II</productname> プロセスの stdout および stderr
+ は単にログファイルにリダイレクトされていました。
+ これは複数プロセスが同時に書き込みを行うため競合が発生し、
+ ログの文字化けや失敗の原因となっていました。
+ </para>
+ <para>
+ <!--
To fix this, <link linkend="PGPOOL-SETUP">pgpool_setup </link> now generates startall script so that pgpool
now sends stdout/stderr to cat command and cat writes to the log file
(It seems the race condition does not occur when writing to a pipe).
+ -->
+ このため、<link linkend="PGPOOL-SETUP">pgpool_setup </link>
+ が生成する startall スクリプトでは、<productname>Pgpool-II</productname>
+ は stdout/stderr を cat コマンドにパイプで送信し、
+ cat がログファイルの書き込みを行うように修正されました。
</para>
</listitem>
<listitem>
@@ -1252,14 +1541,22 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
2016-03-07 [e55c230] Fix for [pgpool-general: 4519] Worker Processes Exit and Are Not Re-spawned
-->
<para>
+ <!--
Fix for <ulink url="http://www.pgpool.net/pipermail/pgpool-general/2016-March/004577.html">
[pgpool-general: 4519]</ulink> Worker Processes Exit and Are Not Re-spawned. (Muhammad Usama)
+ -->
+ <ulink url="http://www.pgpool.net/pipermail/pgpool-general/2016-March/004577.html">
+ [pgpool-general: 4519]</ulink> により報告された子プロセスが終了し再生成されなくなる不具合を修正しました。(Muhammad Usama)
</para>
<para>
+ <!--
The problem was due to a logical mistake in the code for checking the exiting
child process type when the watchdog is enabled.
I have also changed the severity of the message from FATAL to LOG, emitted
for child exits due to max connection reached.
+ -->
+ この問題は watchdog が有効のときに終了した子プロセスのタイプをチェックするコードにロジック間違いがあったのが原因でした。
+ また、接続が max connection に達して子プロセスが終了する際に出力されるメッセージの重要度を FATAL からLOG に変更されました。
</para>
</listitem>
<listitem>
@@ -1267,20 +1564,16 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
2016-03-04 [67ac541] Fix pgpool hung after receiving error state from backend
-->
<para>
+ <!--
Fix pgpool hung after receiving error state from backend. (bug #169) (Tatsuo Ishii)
+ -->
+ バックエンドからエラー状態を受信した直後のハングを修正しました。 (bug #169) (Tatsuo Ishii)
</para>
<para>
- This could happend if we execute an extended protocol query and it
- fails. After an error is received the "ignore till sync flag" is set
- and remained even if sync message was actually received. Thus any
- subsequent query (in the case above "DEALLOCATE message") is not
- procesed and pgpool waits for message from frontend and backend, and
- pgpool stucks here because no message will arrive from both side.
- </para>
- <para>
- To fix this, unconditionally reset the "ignore till sync flag" in
- <function>ReadyforQuery()</function>. This is safe because apparently we already received
- the ready for query message.
+ <!--
+ This could happend if we execute an extended protocol query and it fails.
+ -->
+ これは拡張プロトコル問い合わせを実行しそれが失敗したときに発生し得ました。
</para>
</listitem>
<listitem>
@@ -1288,7 +1581,11 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
2016-03-03 [bb295a2] Fix query stack problems in extended protocol case.
-->
<para>
+ <!--
Fix query stack problems in extended protocol case. (bug 167, 168) (Tatstuo Ishii)
+ -->
+ ストリーミングレプリケーションモードで拡張プロトコル問い合わせを使用したときに
+ スタックが発生する問題を修正しました。(bug 167, 168) (Tatsuo Ishii)
</para>
<para>
</para>
@@ -1298,14 +1595,24 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
2016-03-03 [63a0b70] Fix yet another reset query stuck problem
-->
<para>
+ <!--
Fix <ulink url="http://www.pgpool.net/pipermail/pgpool-hackers/2016-March/001440.html">
[pgpool-hackers: 1440]</ulink> yet another reset query stuck problem. (Tatsuo Ishii)
+ -->
+ <ulink url="http://www.pgpool.net/pipermail/pgpool-hackers/2016-March/001440.html">
+ [pgpool-hackers: 1440]</ulink> により報告されたリセットクエリがスタックする問題を修正しました。(Tatsuo Ishii)
</para>
<para>
+ <!--
After receiving X message from frontend, if <productname>Pgpool-II</productname> detects EOF on
the connection before sending reset query, <productname>Pgpool-II</productname> could wait for
backend which had not received the reset query. To fix this, if EOF
received, treat this as FRONTEND_ERROR, rather than ERROR.
+ -->
+ フロントエンドから 'X' メッセージを受信した後、リセットクエリ送信前に <productname>Pgpool-II</productname> が
+ EOF をその接続で検出すると、<productname>Pgpool-II</productname>
+ がリセットクエリを受信していないバックエンドからの応答を待ち続けることがありました。
+ EOF を受信した場合には、これを ERROR ではなく FRONTEND_ERROR として扱うことで修正しました。
</para>
</listitem>
<listitem>
@@ -1313,12 +1620,19 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
2016-02-22 [f1cfeb6] Yet another reset query stuck problem fix. [pgpool-general: 4265]
-->
<para>
+ <!--
Fix for <ulink url="http://www.pgpool.net/pipermail/pgpool-general/2015-December/004323.html">
[pgpool-general: 4265]</ulink> another reset query stuck problem. (Muhammad Usama)
+ -->
+ <ulink url="http://www.pgpool.net/pipermail/pgpool-general/2015-December/004323.html">[pgpool-general: 4265]</ulink>
+ より報告されたリセットクエリがスタックする問題を修正しました。(Muhammad Usama)
</para>
<para>
+ <!--
The solution is to report FRONTEND_ERROR instead of simple ERROR when
pool_flush on front-end socket fails.
+ -->
+ フロントエンドソケットにおける pool_flush が失敗したときには、ERRORではなく FRONTEND_ERROR を発生させることで解決しました。
</para>
</listitem>
<listitem>
@@ -1326,11 +1640,18 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
2016-02-12 [c50f357] Fixing pgpool-recovery module compilation issue with PostgreSQL 9.6
-->
<para>
+ <!--
Fixing pgpool-recovery module compilation issue with <productname>PostgreSQL</productname> 9.6. (Muhammad Usama)
+ -->
+ PostgreSQL 9.6 における pgpool-recovery モジュールのコンパイルエラーを修正しました。(Muhammad Usama)
</para>
<para>
+ <!--
Incorporating the change of function signature for
<function>GetConfigOption()</function> functions in <productname>PostgreSQL</productname> 9.6
+ -->
+ <productname>PostgreSQL</productname> 9.6 の <function>GetConfigOption()</function>
+ 関数の関数定義の変化に対応しました。
</para>
</listitem>
<listitem>
@@ -1338,11 +1659,18 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
2016-02-03 [48e9d4b] Fix for [pgpool-II 0000166]: compile issue on freebsd
-->
<para>
- Fix compile issue on freebsd. (Muhammad Usama)
+ <!--
+ Fix compile issue on freebsd. (Muhammad Usama)
+ -->
+ FreeBSD でのコンパイルエラーを修正しました。(Muhammad Usama)
</para>
<para>
+ <!--
Add missing include files. The patch is contributed by
the bug reporter and enhanced a little by me.
+ -->
+ 不足していた include ファイルを追加しました。
+ パッチはバグ報告者によって作成され、Usama により改善されました。
</para>
</listitem>
<listitem>
@@ -1350,20 +1678,10 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
2016-02-01 [6688332] Fix regression test to check timeout of each test
-->
<para>
+ <!--
Fix regression test to check timeout of each test. (Yugo Nagata)
- </para>
- </listitem>
- <listitem>
- <!--
- 2016-02-01 [44f43cc] Add some warning messages for wd_authkey hash calculation failure
-->
- <para>
- Add some warning messages for <xref linkend="guc-wd-authkey"> hash calculation failure. (Yugo Nagata)
- </para>
- <para>
- Sometimes <xref linkend="guc-wd-authkey"> calculation fails for some reason other than
- authkey mismatch. The additional messages make these distingushable
- for each other.
+ 個々のテストのタイムアウトをチェックできるようレグレッションテストを修正しました。(Yugo Nagata)
</para>
</listitem>
diff --git a/doc.ja/src/sgml/release.sgml b/doc.ja/src/sgml/release.sgml
index de8a3fd95..d77b24c45 100644
--- a/doc.ja/src/sgml/release.sgml
+++ b/doc.ja/src/sgml/release.sgml
@@ -45,27 +45,44 @@ For new features, add links to the documentation sections.
<title>リリースノート</title>
<para>
+ <!--
The release notes contain the significant changes in each
<productname>Pgpool-II</> release, with major features and migration
issues listed at the top. The release notes do not contain changes
that affect only a few users or changes that are internal and therefore not
user-visible.
+ -->
+ このリリースノートには、<productname>Pgpool-II</productname> の各リリースでなされた重要な変更点が記載されています。
+ また、主要機能や移行に関する問題点も最初に記載されています。
+ リリースノートにはごく一部のユーザにしか影響しない変更点や内部的なものであるためユーザには隠れている変更点は記載されていません。
</para>
<para>
+ <!--
A complete list of changes for each release can be obtained by
- viewing the <!--<link linkend="git">-->Git<!--</link>--> logs for each release.
+ viewing the Gitlogs for each release.
The <ulink
url="http://www.pgpool.net/pipermail/pgpool-committers/"><literal>pgpool-committers</literal>
email list</ulink> records all source code changes as well. There is also
a <ulink url="http://git.postgresql.org/gitweb?p=pgpool2.git;a=summary">web
interface</ulink> that shows changes to specific files.
+ -->
+ 各リリースにおける変更点の全一覧は、各リリースの
+ <!--<link linkend="git">-->Git<!--</link>--> ログを参照することで入手できます。
+ <ulink url="http://www.pgpool.net/pipermail/pgpool-committers/"><literal>pgpool-committers</literal></ulink>
+ メーリングリストにもすべてのソースコードの変更点が記録されています。
+ また、特定のファイルに対する変更点を表示する Web インタフェースが存在します。
</para>
<para>
+ <!--
The name appearing next to each item represents the major developer for
that item. Of course all changes involve community discussion and patch
review, so each item is truly a community effort.
+ -->
+ 各項目の後に記述した名前は、その項目の主な開発者の名前です。
+ もちろんすべての変更はコミュニティによる議論やパッチレビューが行われていますので、
+ 各項目は本当はコミュニティによるものと言えます。
</para>
<!--
diff --git a/doc/src/sgml/release-3.6.sgml b/doc/src/sgml/release-3.6.sgml
index 9f92a95b9..7b07f0782 100644
--- a/doc/src/sgml/release-3.6.sgml
+++ b/doc/src/sgml/release-3.6.sgml
@@ -199,36 +199,10 @@
Sync inconsitent status
of <productname>PostgreSQL</productname> nodes
in <productname>Pgpool-II</productname> instances after
- restart. (Muhammad Usama)
+ restart. (bug 218) (Muhammad Usama)
</para>
<para>
- At the <productname>Pgpool-II</productname> startup, the
- status of each configured backend node is loaded from the
- backend status file or otherwise initialized by querying the
- backend nodes. This technique works fine in stand alone mode
- and also with the watchdog enabled as long as the status of
- backend nodes remains consistent until
- all <productname>Pgpool-II</productname> nodes got up and
- running. But since <productname>Pgpool-II</productname>
- does not sync the backend node status from the watchdog
- cluster at startup time, so in some cases
- the <productname>Pgpool-II</productname> nodes participating
- in the watchdog cluster may get a different status for the
- same backend, especially if
- the <productname>Pgpool-II</productname> nodes part of the
- watchdog cluster starts at different times and between that
- time an unavailable backend PostgreSQL node had become
- available again.
- </para>
- <para>
- So to solve this, the commit implements the new startup
- procedure for the
- standby <productname>Pgpool-II</productname>, And now the
- standby
- <productname>Pgpool-II</productname> will load the backend
- status of all
- configured <productname>PostgreSQL</productname> nodes from
- the watchdog master/coordinator node at the time of startup.
+ Watchdog does not synchronize status.
</para>
</listitem>
@@ -286,85 +260,6 @@
In some cases pg_terminate_backend() now does not trigger a
fail-over. (Muhammad Usama)
</para>
- <para>
- Since the pg_terminate_backend function
- in <productname>PostgreSQL</productname> is used to
- terminate the backend connection, So what happens is, when
- this function kills a <productname>PostgreSQL</productname>
- backend that is connected to
- the <productname>Pgpool-II</productname>, This disconnection
- of backend by pg_terminate_backend function is appeared as a
- backend node failure to
- the <productname>Pgpool-II</productname>. But the problem
- here is, PostgreSQL does not give any information to the
- client program that the connection is going to be killed
- because of the pg_terminate_backend call and on the client
- side, it looks similar to the backend node failure.
- </para>
- <para>
- Now to solve this in <productname>Pgpool-II</productname> we
- need two things. First is to identify the
- pg_terminate_backend function in the query and the
- <productname>Pgpool-II</productname> child process that
- hosts the particular backend connection which will be killed
- by that pg_terminate_backend function call, so that we get a
- heads up in advance about the backend termination, and
- secondly the routing of the query containing
- pg_terminate_backend also needs a new logic so that the
- query should be sent to the correct PostgreSQL node that
- hosts the backend with the PID referred by the
- pg_terminate_bakend()
- </para>
- <para>
- So how does this commit handles pg_terminate_backend()?? In
- the SimpleQuery() function which is the work horse of simple
- query processing in the <productname>Pgpool-II</productname>
- we start with the search of the pg_terminate_backend()
- function call in the query parse tree and if the search
- comes out to be successful, the next step is to locate
- the <productname>Pgpool-II</productname> child process and a
- backend node of that connection whose PID is specified in
- pg_terminate_backend function's argument. Once the
- connection and the <productname>Pgpool-II</productname>
- child process is identified, we just set the
- swallow_termination flag(added by this commit in
- ConnectionInfo structure) for that connection in the shared
- memory, and also set the query destination node to the
- backend node that hosts that particular connection and does
- not call pool_where_to_send() for this query so that the
- query should be sent to the correct backend node.
- </para>
- <para>
- Now when the query is routed to the correct node and
- consequently the backend gets killed, that results in the
- communication error on <productname>Pgpool-II</productname>
- side, the <productname>Pgpool-II</productname> already knows
- that this disconnection is due the pg_terminate_backend and
- not because of node failure as the swallow_termination flag
- is already set for the connection.
- </para>
- <para>
- Some works are still remaining.
- </para>
- <para>
- pg_terminate_backend is not handled with extended query
- protocol.
- </para>
- <para>
- Currently we only support
- pg_terminate_backend(constant number) function calls. If the
- expression or sub query is used in the argument of
- pg_terminate_backend then it would not be handled e.g
- <programlisting>
-pgpool=# select pg_terminate_backend(1025); -- Supported
-pgpool=# select pg_terminate_backend( 2 +1); -- NOT SUPPORTED
-pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
- </programlisting>
- </para>
- <para>
- Currently only one pg_terminate_backend call in a query is
- handled.
- </para>
</listitem>
<listitem>
@@ -414,12 +309,6 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
<para>
Tighten up health check timer expired condition in pool_check_fd(). (Muhammad Usama)
</para>
- <para>
- Check if the signal was actually the health check timer
- expire to make sure that we do not declare the timer expire
- due to some other signal arrived while waiting for data for
- health check in pool_check_fd().
- </para>
</listitem>
<listitem>
@@ -493,7 +382,7 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-05-23 [9342472] Permit pgpool to support multiple SSL cipher protocols
-->
<para>
- Allow to use multiple SSL cipher protocols. (Multiple Usama)
+ Allow to use multiple SSL cipher protocols. (Muhammad Usama)
</para>
<para>
By replacing TLSv1_method() with SSLv23_method() while
@@ -664,39 +553,13 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
<para>
Fix a problem with the watchdog <xref linkend="guc-failover-command"> locking mechanism. (Muhammad Usama)
</para>
- <para>
- From <productname>Pgpool-II</productname> 3.5 watchdog was using the separate individual locks for each
- node-failover command (failover, failback and follow-master) and the lock was
- acquired just before executing the respective failover script and was released
- as soon as the script execution finishes. This technique although was very
- efficient but also had a problem. If the <xref linkend="guc-failover-command"> takes a very little
- time and gets finished before the lock request from other <productname>Pgpool-II</productname> node
- arrives, the other node is also granted a lock, since the lock was already
- released by the first node at that time. Consequently, both nodes ends up
- executing the failover script.
- So to fix this we are reverting back to the tested failover interlocking design
- used prior to <productname>Pgpool-II</productname> 3.5 where all the commands gets locked at the failover
- start by the node that becomes a lock-holder and each command lock is released
- after its execution finishes. And only the lock-holder node is allowed to
- acquire/release the individual command lock. That way the lock-holder node
- keeps the lock-holder status throughout the span of the failover execution and
- the system becomes less time sensitive.
- </para>
</listitem>
<listitem>
<!--
2016-09-12 [b412da2] Disable strict aliasing optimization.
-->
<para>
- Disable strict aliasing optimization. (Tatsuo Ishii)
- </para>
- <para>
- <function>flatten_set_variable_args()</function> was imported from <productname>PostgreSQL</productname>
- in <productname>Pgpool-II</productname>
- 3.5. To make the code work, a compiler flag <option>-fno-strict-aliasing</option> is
- necessary (<productname>PostgreSQL</productname> does so). Unfortunately when the function was
- imported, the compiler flag was not added. To fix this, <filename>configure.ac</filename>
- was modified.
+ Add compiler flag "-fno-strict-aliasing" in <filename>configure.ac</filename> to fix compiler error. (Tatsuo Ishii)
</para>
</listitem>
<listitem>
@@ -721,15 +584,6 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
<para>
Don't ignore sync message from frontend when query cache is enabled. (Tatsuo Ishii)
</para>
- <para>
- While returning cached query result, sync message sent from frontend
- is discarded. This is harmless because "ready for query" messages is
- sent to frontend afterward. Problem is, AccessShareLock held by
- previous parse message processing is not released until sync message
- is received by the backend. Fix is, forwarding the sync message to
- backend and discarding "ready for query" message returned from
- backend.
- </para>
</listitem>
<listitem>
<!--
@@ -758,25 +612,14 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
<para>
Fixing the error messages when the socket operation fails. (Muhammad Usama)
</para>
- <para>
- When some socket operation fails, we issue close socket before throwing an
- error which causes the errno value to be overwritten and consequently the error
- log does not print the correct failure reason.
- The solution is to save the errno before closing the socket and use the saved
- value to print error description.
- </para>
</listitem>
<listitem>
<!--
2016-08-15 [f2b5d17] Fix regression failure of 003.failover.
-->
<para>
- Fix regression failure of 003.failover. (Tatsuo Ishii)
- </para>
- <para>
- Update expected data to reflect the changes made to <link linkend="SQL-SHOW-POOL-NODES">show pool_nodes</link>.
- Also fix <link linkend="SQL-SHOW-POOL-NODES">show pool_nodes</link> to proper use "_" instead of space for the
- column name.
+ Update regression test 003.failover to reflect the changes made to
+ <link linkend="SQL-SHOW-POOL-NODES">show pool_nodes</link>. (Tatsuo Ishii)
</para>
</listitem>
<listitem>
@@ -786,13 +629,6 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
<para>
Fix hang when portal suspend received. (bug 230) (Tatsuo Ishii)
</para>
- <para>
- When portal suspend message is received, it's not enough to forward it
- to the client. Since backend expects to receive execute message,
- trying to read further more messages from backend will never
- succeed. To fix this, turn off the query in progress flag, which will
- pole incoming message from the client.
- </para>
</listitem>
<listitem>
<!--
@@ -821,36 +657,6 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
</para>
</listitem>
<listitem>
- <!--
- 2016-08-02 [bda946e]Fix for 218: Inconsistent status of Postgresql nodes in pgPool instances
- after restart. Watchdog not syncing status.
- -->
- <para>
- Fix for bug of inconsistent status of <productname>PostgreSQL</productname> nodes in <productname>Pgpool-II</productname> instances
- after restart. (bug 218) (Muhammad Usama)
- </para>
- <para>
- Watchdog does not synchronize status.
- Currently at the <productname>Pgpool-II</productname> startup, The status of each configured backend node
- is loaded from the backend status file or otherwise initialized by querying the
- backend nodes. This technique works fine in stand alone mode and also with
- the watchdog enabled as long as the status of backend nodes remains consistent
- until all <productname>Pgpool-II</productname> nodes got up and running.
- But since <productname>Pgpool-II</productname> does not sync the backend node status from the
- watchdog cluster at startup time, so in some cases the pgpool-II nodes
- participating in the watchdog cluster may get a different status for the same
- backend, especially if the <productname>Pgpool-II</productname> nodes part of the watchdog cluster starts
- at different times and between that time an unavailable backend <productname>PostgreSQL</productname> node
- had become available again.
- </para>
- <para>
- So to solve this, the commit implements the new startup procedure for the
- standby <productname>Pgpool-II</productname>, And now the standby <productname>Pgpool-II</productname> will load the backend status of
- all configured <productname>PostgreSQL</productname> nodes from the watchdog master/coordinator node
- at the time of startup.
- </para>
- </listitem>
- <listitem>
<!--
2016-08-01 [024eaea] Fix for 215: pgpool doesnt escalate ip in case of another node inavailability
-->
@@ -945,12 +751,9 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
Fix usage of <function>wait(2)</function> in pgpool main process. (Tatsuo Ishii)
</para>
<para>
- When child process dies, SIGCHLD signal is raised and <function>wait(2)</function> knows
- the event. However, multiple child death does not necessarily creates
- exact same number of SIGCHLD signal as the number of dead children and
- <function>wait(2)</function> could wait for an event which never happens in this case. I
- Actually encountered this situation while testing <productname>Pgpool-II</productname>. Solution
- is, to use <function>waitpid(2)</function> instead of <function>wait(2)</function>.
+ The usage of <function>wait(2)</function> in <productname>Pgpool-II</productname>
+ main could cause infinite wait in the system call. Solution is,
+ to use <function>waitpid(2)</function> instead of <function>wait(2)</function>.
</para>
</listitem>
<listitem>
@@ -958,13 +761,8 @@ pgpool=# select pg_terminate_backend((select 1)); -- NOT SUPPORTED
2016-06-28 [bb41a1e] Fix confusing error messages.
-->
<para>
- Fix confusing error messages. (Tatsuo Ishii)
- </para>
- <para>
- <function>pool_read()</function> does not emit error messages when <function>read(2)</function> returns -1 if
- <xref linkend="guc-fail-over-on-backend-error"> is off. In any case the cause of error
- should be emitted. I do not back port this because it's a too trivial
- enhancement.
+ Fix that <function>pool_read()</function> does not emit error messages when <function>read(2)</function> returns -1 if
+ <xref linkend="guc-fail-over-on-backend-error"> is off. (Tatsuo Ishii)
</para>
</listitem>
<listitem>
@@ -1077,16 +875,6 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
either load balance node or primary node, the primary node id is
returned.
</para>
- <para>
- For master and 3.5-stable, additional fixes/enhancements are made:
- <function>pool_extended_send_and_wait()</function> now issues flush message if the request
- is 'E' (execute). Before it was issued outside (in Execute), but this
- makes the logic to determine to which node the flush message to be
- sent unnecessary complex.
- </para>
- <para>
- A debug message in pool_write is enhanced by adding backend node id.
- </para>
</listitem>
<listitem>
<!--
@@ -1104,7 +892,10 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
the statement timeout timer if we are in an explicit transaction. We
cannot use this technique for implicit transaction case, because the
sync message removes the unnamed portal if there's any.
-
+ </para>
+ <para>
+ Plus, pg_stat_statement will no longer show the query issued by
+ do_query() as "running".
</para>
<para>
Plus, pg_stat_statement will no longer show the query issued by
@@ -1185,7 +976,7 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
-->
<para>
Fix for <ulink url="http://www.pgpool.net/pipermail/pgpool-general/2016-March/004627.html">
- [pgpool-general: 4569]</ulink> <productname>Pgpool-II</productname> 3.5 : segfault. (Muhammad Usama)
+ [pgpool-general: 4569]</ulink> segfault during trusted_servers check. (Muhammad Usama)
</para>
<para>
PostgreSQL's memory and exception manager APIs adopted by the <productname>Pgpool-II</productname> 3.4 are not
@@ -1197,7 +988,7 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
</listitem>
<listitem>
<!--
- 2016-05-29 [f7723c8] Validating the PCP packet length
+ 2016-03-29 [f7723c8] Validating the PCP packet length
-->
<para>
Validating the PCP packet length. (Muhammad Usama)
@@ -1209,26 +1000,6 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
</para>
</listitem>
<listitem>
- <!--
- 2016-03-28 [f305fbe] Fix pgpool hang bug (deal with bug 167)
- -->
- <para>
- Fix <productname>Pgpool-II</productname> hang bug (bug 167). (Tatsuo Ishii)
- </para>
- <para>
- <productname>Pgpool-II</productname> 3.5 or after in streaming replication mode does not wait for
- response from each phase such parse, bind anymore. However, if
- do_query is called, it sends flush message to retrieve the result of
- system catalog look up. This is only sent to primary node which may
- results in retrieving previous message results, for example parse
- complete. If standby is assigned to load balance node, the node does
- not return parse complete message, which will cause a problem in
- bug167 case, because parse message for "BEGIN" was sent to both the
- primary and the standby. Fix is, send flush message in do_query if the
- load balance node is one of standbys.
- </para>
- </listitem>
- <listitem>
<!--
2016-03-26 [d1c03f2] Fix pgpool_setup to not confuse log output
-->
@@ -1271,16 +1042,7 @@ ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancin
</para>
<para>
This could happend if we execute an extended protocol query and it
- fails. After an error is received the "ignore till sync flag" is set
- and remained even if sync message was actually received. Thus any
- subsequent query (in the case above "DEALLOCATE message") is not
- procesed and pgpool waits for message from frontend and backend, and
- pgpool stucks here because no message will arrive from both side.
- </para>
- <para>
- To fix this, unconditionally reset the "ignore till sync flag" in
- <function>ReadyforQuery()</function>. This is safe because apparently we already received
- the ready for query message.
+ fails.
</para>
</listitem>
<listitem>
[parent: e7b94b6613e5]