[pgpool-general-jp: 1380] Re: ドキュメントバグ？ Streaming Replicationでのクエリ振り分けについて

[Kazuki Uehara]

SRA OSS石井様

上原です。
お世話になっております。


ご確認いただきありがとうございます。
マニュアルの修正、よろしくお願いします。

五月雨になってしまい申し訳ないのですが、「SHOW」もDECLAREと同様で
PRIMARYに振られているようです。（pgpool-II 3.4.2）
マニュアルではロードバランシングの対象と記載されているので、DECLARE
と合わせて修正いただけると幸いです。


以下、確認ログです。

念のため、src/context/pool_query_context.cに以下のデバッグログを入れて
確認しております。

----------------
        /*
         * Other statements are sent to primary
         */
        ereport(LOG,(errmsg("[debug_k] Other statements")));←★追加
        return POOL_PRIMARY;
    }
--------------


$ psql -h 192.168.1.3 -p 9999 -U user1 testdb -c "show SERVER_VERSION"

pgpool.log
---------
2015-08-04 19:30:29: pid 15678: LOG:  [debug_k] Other statements
2015-08-04 19:30:29: pid 15678: LOG:  DB node id: 0 backend pid: 13625 statement: show SERVER_VERSION
---------



> ところで2.2.6のコミットログ(ed5a6338cc83fc00ffdac89025eb7a59d6024d4b)を
> 見直してみると、"Fix is_select_query() not to allow cursor statements.
> Close() should not allowed since hold cursor + update may cause data
> inconsistency." とあるのですが、正直自分がコミットしたにも関わらず自分
> でもなぜこのように考えたのか覚えていません:-)
>
> うーん、思い出せるかどうか頑張ってみます。


＜以下、余談です。＞

試しにDECLAREをロードバランシングさせてみたのですが、以下のようなエラー
が出力されました。

実施概要：JDBC使用（AutoCommit　OFF）
　　　　　DECLARE後にFETCHを何回か実行する

pgpool.log
---------------
2015-08-04 19:55:53: pid 16692: LOG:  DB node id: 0 backend pid: 13731 statement: Execute: BEGIN
2015-08-04 19:55:53: pid 16692: LOG:  DB node id: 1 backend pid: 24379 statement: Execute: BEGIN
2015-08-04 19:55:53: pid 16692: LOG:  DB node id: 1 backend pid: 24379 statement: Parse: DECLARE cur2 CURSOR WITH HOLD FOR SELECT * FROM bar2
2015-08-04 19:55:53: pid 16692: LOG:  DB node id: 1 backend pid: 24379 statement: B message
2015-08-04 19:55:53: pid 16692: LOG:  DB node id: 1 backend pid: 24379 statement: D message
2015-08-04 19:55:53: pid 16692: LOG:  DB node id: 1 backend pid: 24379 statement: Execute: DECLARE cur2 CURSOR WITH HOLD FOR SELECT * FROM bar2
2015-08-04 19:55:53: pid 16692: LOG:  [debug_k] Other statements
2015-08-04 19:55:53: pid 16692: LOG:  DB node id: 0 backend pid: 13731 statement: Parse: FETCH FIRST FROM cur2
2015-08-04 19:55:53: pid 16692: LOG:  DB node id: 0 backend pid: 13731 statement: B message
2015-08-04 19:55:53: pid 16692: LOG:  DB node id: 0 backend pid: 13731 statement: D message
2015-08-04 19:55:53: pid 16692: LOG:  DB node id: 0 backend pid: 13731 statement: Execute: FETCH FIRST FROM cur2
2015-08-04 19:55:53: pid 16692: LOG:  pool_send_and_wait: Error or notice message from backend: : DB node id: 0 backend pid: 13731 statement: "FETCH FIRST FROM cur2" message: "cursor "cur2" does not exist"
2015-08-04 19:55:53: pid 16692: LOG:  DB node id: 1 backend pid: 24379 statement: ABORT
2015-08-04 19:55:53: pid 16692: LOG:  DB node id: 0 backend pid: 13731 statement: ABORT
----------------

DECLAREをnode:1で実行したあとにFETCHがnode:0に向いていたのでエラーに
なっていました。ですので、もしカーソル系を分散させたいなら全nodeに
DECLAREをしたりするのでしょうか？
# もともと外された理由を理解できていないので、トンチンカンなことを
　言っていたらすみません。


以上です。
よろしくお願いします。


(2015/08/04 17:48), Tatsuo Ishii wrote:
> 上原様
> 
> お世話になっています。SRA OSS石井です。
> 
>> 上原と申します。
>> お世話になっております。
>>
>> pgpool-II 3.4.2 でロードバランシングの対象となるSQLについて確認して
>> いたところ、マニュアルの記述に誤りと思われる箇所がありました。
>> ご確認いただけないでしょうか。
>>
>> ---------
>> ○Streaming Replicationでのクエリ振り分け
>> ・Primary/Standbyどちらにも送ることのできる問い合わせ。
>> 　- DECLARE, FETCH, CLOSE
>> ---------
>> （pgpool-II マニュアルから一部抜粋）
>>
>> 上記のように記載されているのですが、確認したところカーソル系のSQLは
>> ロードバランシングの対象とはなっておらず、全てPrimaryに向けられて
>> いるようです。
>>
>> src/context/pool_query_context.c
>> send_to_where()
>> -------
>> 1213                 /*
>> 1214                  * Other statements are sent to primary
>> 1215                  */
>> 1216                 return POOL_PRIMARY;
>> -------
>> ここで、DeclareCursorStmtはPOOL_PRIMARYに落ちているかと思います。
>>
>>
>> # 調べた後で気づきましたが、
>>    2.2.6 のリリースノートにDECLAREをロードバランシングの対象から外した
>>    という記述がありましたので、おそらくその時期から残っていたのかと思います。
> 
> 仰るとおりで、マニュアルの記述が更新されていないようです。修正いたします。
> ご指摘ありがとうございました。
> 
> ところで2.2.6のコミットログ(ed5a6338cc83fc00ffdac89025eb7a59d6024d4b)を
> 見直してみると、"Fix is_select_query() not to allow cursor statements.
> Close() should not allowed since hold cursor + update may cause data
> inconsistency." とあるのですが、正直自分がコミットしたにも関わらず自分
> でもなぜこのように考えたのか覚えていません:-)
> 
> うーん、思い出せるかどうか頑張ってみます。
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp


-- 
上原　一樹 (Kazuki Uehara)
Mail : uehara.kazuki ＠ lab.ntt.co.jp
Phone: 03-5860-5115