PostgreSQL/Pgpool-II/タイムアウト関係 のバックアップ(No.1)

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• PostgreSQL/Pgpool-II/タイムアウト関係 へ行く。
  • 1 (2018-02-01 (木) 08:28:26)
  • 2 (2018-02-01 (木) 08:37:40)
  • 3 (2018-02-03 (土) 06:58:04)
  • 4 (2018-02-04 (日) 22:32:14)
  • 5 (2018-02-11 (日) 08:36:27)

---

PostgreSQL/Pgpool-II

Pgpool-IIのタイムアウト関連のパラメータ及び設定など †

ざっと調べたところ、以下のようになっている。特に、connect_timeoutは、共通して色々なところで使われ、health_check_timeoutとも関連している。システムのタイムアウトの設計をするときには要確認。

クエリ実行中の動作 †

• backendからの応答を、selectで30secタイムアウトで待つ。
• 30secタイムアウトした後は、frontendに対してダミーのパラメータ状態報告（ParameterStatus (B)）を送り、frontendへのソケット書き込みが成功するか否かをチェックしている（ただし、TCPではfrontendの接続が既に閉じられていてFINを送られていてもwriteは可能である。最初のwriteでRSTが誘発され、続くwriteでSIGPIPEが送られることとなる）。

参考

• wait_for_query_response() - on https://git.postgresql.org/gitweb/?p=pgpool2.git
• PostgreSQL 9.6.5文書 51.5. メッセージの書式 - on https://www.postgresql.jp/document/9.6/html/
• http://www.kt.rim.or.jp/~ksk/sock-faq/unix-socket-faq-ja-2.html

以下はwait_for_query_response関数実行時のスタックトレースである。pool_check_fd内でselectを使ってbackendの応答を待つ。

  * frame #0: 0x000000010cf0100f pgpool`pool_check_fd(cp=0x000000010d15f078) at pool_process_query.c:627
    frame #1: 0x000000010cf00e53 pgpool`wait_for_query_response(frontend=0x00007f967b817438, backend=0x000000010d15f078, protoVersion=3) at pool_process_query.c:494
    frame #2: 0x000000010cf00cfd pgpool`wait_for_query_response_with_trans_cleanup(frontend=0x00007f967b817438, backend=0x000000010d15f078, protoVersion=3, pid=-2027356160, key=-239764672) at pool_process_query.c:453
    frame #3: 0x000000010cf2c533 pgpool`pool_send_and_wait(query_context=0x00007f967c803038, send_type=1, node_id=0) at pool_query_context.c:817
    frame #4: 0x000000010cf11121 pgpool`SimpleQuery(frontend=0x00007f967b817438, backend=0x00007f967b801648, len=19, contents="select * from foo;") at pool_proto_modules.c:635
    frame #5: 0x000000010cf18cde pgpool`ProcessFrontendResponse(frontend=0x00007f967b817438, backend=0x00007f967b801648) at pool_proto_modules.c:2358
    frame #6: 0x000000010cf00a60 pgpool`read_packets_and_process(frontend=0x00007f967b817438, backend=0x00007f967b801648, reset_request=0, state=0x00007ffee2d2cba4, num_fields=0x00007ffee2d2cbc2, cont="\x01\376) at pool_process_query.c:4731
    frame #7: 0x000000010cefebea pgpool`pool_process_query(frontend=0x00007f967b817438, backend=0x00007f967b801648, reset_request=0) at pool_process_query.c:226
    frame #8: 0x000000010cef85b3 pgpool`do_child(fds=0x00007f967b402af0) at child.c:383
    frame #9: 0x000000010cece480 pgpool`fork_a_child(fds=0x00007f967b402af0, id=0) at pgpool_main.c:607
    frame #10: 0x000000010cecb366 pgpool`PgpoolMain(discard_status='\x01', clear_memcache_oidmaps='\0') at pgpool_main.c:363
    frame #11: 0x000000010cec9838 pgpool`main(argc=9, argv=0x00007ffee2d377f8) at main.c:318
    frame #12: 0x00007fff7502d115 libdyld.dylib`start + 1
    frame #13: 0x00007fff7502d115 libdyld.dylib`start + 1

ereportで、エラーレベルFRONTEND_ERRORが指定されているので、ここに到達するとスタックの上流のPG_CATCH()に飛び、さらにPG_RE_THROW()されsigsetjmpのPG_exception_stackで指定されたポイントに制御が移る。エラーハンドリング内では、セッションクローズするための処理を行なっている。

参考リンク †

• ファイルオーバ
  • http://www.pgpool.net/docs/latest/ja/html/runtime-config-failover.html
• コネクションプール
  • http://www.pgpool.net/docs/latest/ja/html/runtime-config-connection-pooling.html
• ヘルスチェック
  • http://www.pgpool.net/docs/latest/ja/html/runtime-config-health-check.html
• その他ソース
  • wait_for_query_response() - on https://git.postgresql.org/gitweb/?p=pgpool2.git
• setjmp - on https://linuxjm.osdn.jp/html/LDP_man-pages/man3/setjmp.3.html