[pgpool-general-jp: 742] Re: pgpool-II 2.3.2 parallel_mode -client_encoding

[sho]

こんにちは、sho と申します。

この件、現状では制限事項[マルチバイト文字について]に該当していましたね。
クライアントエンコーディングが異なってますから。
あと、set client_encoding を発行しているは、dblink でした。

ただ、気になったので調べてみました。

まず、通常の select * from user_tbl であれば、systemdb を利用しないので、
クライアント(frontend) <-> pgpool <-> backend
                                  <-> backend...
の接続になっています。
この場合、POOL_CONNECTION_POOL の生成時に frontend の　startup_packet を利
用しているので、frontend の client_encoding がセットされているようです。
※ PROTO_MAJOR_V3 の場合しか見てないので、PROTO_MAJOR_V2 の場合はダメかもし
   れません ^^; 以下↓同様

それに対し、select * from user_tbl order by uid などの場合、systemdb を
利用するので、以下のような接続を行っています。

クライアント(frontend) <-> pgpool <-> systemdb (dblink) <-> pgpool <-> backend

このとき、2 段目の pgpool へは dblink が接続するのですが、systemdb と backend
の encoding が同じであれば問題なく、異なってたとしても、たぶん dblink が set
client_encoding を発行しているので大丈夫な気がします。
（未確認）

(a)
問題は 1 段目の fontend と systemdb の接続です。この接続は、pgpool が子プロ
セスを作った段階で make_persistent_db_connection で作成されていますが、まだ
frontend が接続前の段階なので、client_encoding がわかりません。
これを、frontend が接続した段階で make_persistent_db_connection で接続する
ように変更し、startup_packet は frontend の設定を参照するようにすればよいよ
うに思えます。
※ 子プロセス生成時に systemdb への接続を生成する必要がないようにみえる

ただ、frontend が別の client_encoding で再接続された場合は、接続を貼り直す
必要があるかと思いますが。

※ ちなみに、system_db_connect と make_persistent_db_connection で systemdb へ
   2本接続する必要性と、system_db_connect が　libpq を利用して接続し、
   make_persistent_db_connection が自前で接続している理由はなんででしょう？

(b)
もうひとつ、クライアントから明示的に set client_encoding to 'UTF-8' などが
発行された場合は、systemdb と backend 両方に forward できればよいかと。ただ
し、systemdb(dblink) からの同様なコマンドは systemdb へは送らないようにしな
いとまずいと思いますが。

たぶん、これだけではまだまだまずい場合があるかもしれませんが、現状よりは
制約が弱まるのではないかと考えたのですが、どうでしょうか？


以上、宜しくお願いします。

-- sho