pgpool

watchdog exec interface up/down command failed その1

[環境]
pgpool-4.0.4

[現象]
pgpoolの起動時に-nオプションをつけないと、if_up_cmdが失敗する

[原因]
分かりません…、私のやり方が悪いのか、バグなのかすら分からないので、あまりよろしくないのですが、とりあえず-nをつけて起動することにします。

[詳細]
pgpoolはWatchdog機能をONにすると、冗長構成をとることができます。
いろいろ設定し、pgpoolを-nオプションなしで立ち上げた場合、if_up_cmd、pgpoolのための仮想IPアドレスをIFに追加するコマンドが失敗します。
デバッグモードで立ち上げてもなぜ失敗しているかの記録がないのでなぜ失敗するのか分かりません。
[pgpool@erogamescape14 ~]$ /usr/local/pgpool-II-4.0.4/bin/pgpool -d

Apr 27 22:49:21 erogamescape14 [29985]: [37-1] 2019-04-27 22:49:21: pid 29985: DEBUG:  watchdog exec interface up/down command failed
Apr 27 22:49:21 erogamescape14 [29985]: [37-2] 2019-04-27 22:49:21: pid 29985: DETAIL:  'sudo ip addr add $_IP_$/24 dev eth1 label eth1:0' failed. exit status: 1
Apr 27 22:49:21 erogamescape14 [29985]: [38-1] 2019-04-27 22:49:21: pid 29985: LOG:  failed to acquire the delegate IP address
Apr 27 22:49:21 erogamescape14 [29985]: [38-2] 2019-04-27 22:49:21: pid 29985: DETAIL:  'if_up_cmd' failed
Apr 27 22:49:21 erogamescape14 [29985]: [39-1] 2019-04-27 22:49:21: pid 29985: WARNING:  watchdog escalation failed to acquire delegate IP
-nオプションをつけると、成功します。
[pgpool@erogamescape14 ~]$ /usr/local/pgpool-II-4.0.4/bin/pgpool -d -n > /dev/null 2>&1 &

Apr 27 22:51:46 erogamescape14 pgpool[31446]: [37-1] 2019-04-27 22:51:46: pid 31446: DEBUG:  watchdog exec interface up/down command: 'sudo ip addr add $_IP_$/24 dev eth1 label eth1:0' succeeded

理由はわからないですが、-nをつけてpgpoolを起動することにしました。
pgpoolの

pcp_attach_node: invalid option -- 'p'

ErogameScapeの現用サーバーにpgpool-4.0.4をソースからインストールして、pcp_attach_nodeを実行したところ以下のように、-pオプションはないと表示されました。
[ap2@erogamescape14 ~]$ pcp_attach_node -p 8898 -U pgpool 1
pcp_attach_node: invalid option -- 'p'
pcp_attach_node - attach a node from pgpool-II

Usage: pcp_attach_node [-d] timeout hostname port# username password nodeID
Usage: pcp_attach_node -h

  -d       - enable debug message (optional)
  timeout  - connection timeout value in seconds. command exits on timeout
  hostname - pgpool-II hostname
  port#    - pgpool-II port number
  username - username for PCP authentication
  password - password for PCP authentication
  nodeID   - ID of a node to be attached
  -h       - print this help
テストサーバーでは問題なく動いていたので、現用サーバーの問題だと思いました。
そこで「どのpcp_attach_nodeを実行しているか」を確認しました。
[ap2@erogamescape14 ~]$ which pcp_attach_node
/usr/local/bin/pcp_attach_node
ErogameScapeはpgpoolを追える範囲では2.3.3の頃から使っていて、いろいろなverのpcp_attach_nodeが格納されています。
[root@erogamescape14 pgpool]# find / -name pcp_attach_node
中略
/usr/local/pgpool-II-3.5.1/bin/pcp_attach_node
/usr/local/pgpool-II-3.6.0/bin/pcp_attach_node
/usr/local/pgpool-II-3.3.1/bin/pcp_attach_node
/usr/local/pgpool-II-4.0.4/bin/pcp_attach_node
/usr/local/bin/pcp_attach_node
/usr/local/bin/pcp_attach_nodeがいったいいつのverのpcp_attach_nodeなのか分かりません…
[ap2@erogamescape14 ~]$ /usr/local/pgpool-II-4.0.4/bin/pcp_attach_node -p 8898 -U pgpool 1
と実行して、ちゃんと動きました。

Pgpool-IIのヘルスチェック


Pgpool-IIが接続するPostgreSQLがdownしているか?を判断する基準はpgpoolからPostgreSQLに接続を試みたときに接続出来るか?です。

接続する機会がなければ、PostgreSQLはUPしていると判断します。
例を示します。
ap2=# SHOW POOL_NODES ;
 node_id |    hostname    | port | status | lb_weight |  role   | select_cnt | load_balance_node | replication_delay | last_
status_change
---------+----------------+------+--------+-----------+---------+------------+-------------------+-------------------+------
---------------
 0       | localhost      | 5433 | up     | 0.500000  | primary | 7056       | true              | 0                 | 2019-
01-02 22:22:16
 1       | 192.168.86.135 | 5433 | up     | 0.500000  | standby | 4833       | false             | 0                 | 2019-
01-02 22:26:21
(2 rows)
上記の状態のときに、node_idが1のPostgreSQLを落としてみます。
2019/01/02 22:48
[root@postgresql11-testserver-2 ap2]# systemctl stop postgresql-11.service
tail -f /var/log/pgpool/pgpool.logしても、22:48には特にログを出力しません。
[root@postgresql11-testserver-1 ap2]# tail -f /var/log/pgpool/pgpool.log
Jan  2 22:36:52 postgresql11-testserver-1 pgpool[4041]: [863-1] 2019-01-02 22:36:52: pid 4041: LOG:  fork a new child process with pid: 9867
Jan  2 22:52:29 postgresql11-testserver-1 pgpool[4041]: [864-1] 2019-01-02 22:52:29: pid 4041: LOG:  child process with pid: 9476 exits with status 256
Jan  2 22:52:29 postgresql11-testserver-1 pgpool[4041]: [865-1] 2019-01-02 22:52:29: pid 4041: LOG:  fork a new child process with pid: 10914
psql -p 9999でpgpoolに接続を試みます。
この際、node_idが1のPostgreSQLが落ちているので、接続に失敗します。
[ap2@postgresql11-testserver-1 ~]$ psql -p 9999
psql: FATAL:  failed to create a backend connection
DETAIL:  executing failover on backend
tail -f /var/log/pgpool/pgpool.logすると、この時点でpgpoolはnode_1のPostgresqlが落ちていることを検出します。
Jan  2 23:10:50 postgresql11-testserver-1 pgpool[10914]: [865-1] 2019-01-02 23:10:50: pid 10914: LOG:  failed to connect to PostgreSQL server on "192.168.86.135:5433", getsockopt() detected error "Connection refused"
Jan  2 23:10:50 postgresql11-testserver-1 pgpool[10914]: [866-1] 2019-01-02 23:10:50: pid 10914: LOG:  received degenerate backend request for node_id: 1 from pid [10914]
Jan  2 23:10:50 postgresql11-testserver-1 pgpool[10914]: [867-1] 2019-01-02 23:10:50: pid 10914: FATAL:  failed to create a backend connection
もう一度psql -p 9999すれば接続できますが、一度、psql -p 9999が失敗するのは悲しいというケースがあると思います。
その悲しさを解消する機能がヘルスチェック機能です。
ヘルスチェックを有効にすると、pgpool自体が定期的にPostgreSQLに接続を試みて、接続が失敗するとステータスをdownに変更します。

ヘルスチェック機能を有効にしてみます。
[root@postgresql11-testserver-1 ap2]# emacs /etc/pgpool-II/pgpool.conf

- health_check_period = 0
+ health_check_period = 10

- health_check_user = 'nobody'
+ health_check_user = 'postgres'

[root@postgresql11-testserver-1 ap2]# systemctl restart pgpool.service

[root@postgresql11-testserver-2 data]# date ; systemctl stop postgresql-11.service
Wed Jan  2 23:23:25 JST 2019
ヘルスチェックを10秒ごとに実行するよう設定したので、Postgresqlを落としてから10秒以内にdownを検知します。
検知した際のpgpoolのログは以下のようになります。
Jan  2 23:23:30 postgresql11-testserver-1 pgpool[13058]: [6-1] 2019-01-02 23:23:30: pid 13058: LOG:  failed to connect to PostgreSQL server on "192.168.86.135:5433", getsockopt() detected error "Connection refused"
Jan  2 23:23:30 postgresql11-testserver-1 pgpool[13058]: [7-1] 2019-01-02 23:23:30: pid 13058: ERROR:  failed to make persistent db connection
Jan  2 23:23:30 postgresql11-testserver-1 pgpool[13058]: [7-2] 2019-01-02 23:23:30: pid 13058: DETAIL:  connection to host:"192.168.86.135:5433" failed
Jan  2 23:23:30 postgresql11-testserver-1 pgpool[13058]: [8-1] 2019-01-02 23:23:30: pid 13058: LOG:  health check failed on node 1 (timeout:0)
ErogameScapeのようにアクセスが絶え間なくあるWebサービスでPgpoolを使用している場合、ヘルスチェック機能によるdownの検知よりユーザーさんの接続によるdownの検知が早いことがほとんどなので、ヘルスチェック機能を有効にする意味があまりないですが、あまり接続がない用途だったり、Weightを0に設定しているPostgreSQLがある場合は有効にするといいかなと思います。











pgpool_statusファイルについて

pgpool_statusはpgpoolがpostgresqlのdownを検出するとそのdownの状態を記録するファイルです。
例えばnode_idが1のpostgresqlがdownするとpgpool_statusにnode_idが1のpostgresqlがdownしたことが記録されます。

例えば、SHOW POOL_NODESの結果が以下だった場合、
ap2=# SHOW POOL_NODES ;
 node_id |    hostname    | port | status | lb_weight |  role   | select_cnt | load_balance_node | replication_delay | last_
status_change
---------+----------------+------+--------+-----------+---------+------------+-------------------+-------------------+------
---------------
 0       | localhost      | 5433 | up     | 0.500000  | primary | 1          | true              | 0                 | 2019-
01-02 17:43:57
 1       | 192.168.86.135 | 5433 | down   | 0.500000  | standby | 0          | false             | 0                 | 2019-
01-02 20:10:19
(2 rows)
pgpool_statusファイルの内容は以下のようになります。
[ap2@postgresql11-testserver-1 tmp]$ cat pgpool_status
up
down
pgpool_statusファイルはpgpool起動時に読み込まれます。
上記のpgpool_statusファイルの状態でpgpoolを起動すると、node_idが1のpostgresqlがpgpoolに組み込める状態だったとしてもpgpool_statusファイルの2行目(node_idが1)がdownなのでdownであがってきます。
ap2=# SHOW POOL_NODES ;
 node_id |    hostname    | port | status | lb_weight |  role   | select_cnt | load_balance_node | replication_delay | last_
status_change
---------+----------------+------+--------+-----------+---------+------------+-------------------+-------------------+------
---------------
 0       | localhost      | 5433 | up     | 0.500000  | primary | 1          | true              | 0                 | 2019-
01-02 17:43:57
 1       | 192.168.86.135 | 5433 | down   | 0.500000  | standby | 0          | false             | 0                 | 2019-
01-02 20:10:19
(2 rows)
downであがってきて欲しくない場合は、pgpool_statusファイルを消してpgpoolを起動するか、pgpoolを起動する際に、「-D」または「--discard-status」をオプションに指定して起動します。
pgpool

Pgpool-IIのログの出力先の設定について

Pgpool-IIのログの出力先はpgpool.confのlog_destination以降の項目で設定します。

logdirという設定項目がありますが、これはpgpool_statusというファイルを出力するディレクトリを設定する項目です。

※logdirという項目の名前が今となってはイマイチなので、例えばpgpool_status_output_dirのような名前にかえてくれるとうれしいと思っていますが、どこから要望を出したらいいか分かりません…



Pgpool-IIのSHOW POOL_NODESのload_balance_nodeについて

Pgpool-IIのSHOW POOL_NODESのload_balance_nodeはSHOW POOL_NODESを実行したセッションがどのノードを使用しているかを示します。
具体的にはload_balance_nodeがtrueになっているノードに検索クエリを投げます。

例えば、
ap2=# SHOW POOL_NODES ;
 node_id |    hostname    | port | status | lb_weight |  role   | select_cnt | load_balance_node | replication_delay | last_
status_change
---------+----------------+------+--------+-----------+---------+------------+-------------------+-------------------+------
---------------
 0       | localhost      | 5433 | up     | 0.500000  | primary | 0          | true              | 0                 | 2018-
12-29 23:53:02
 1       | 192.168.86.135 | 5433 | up     | 0.500000  | standby | 0          | false             | 0                 | 2018-
12-30 00:01:57
(2 rows)
だった場合は、node_idが0のPostgreSQLに検索クエリを投げます。
SHOW POOL_NODESの悲しいところは、上記の状態でnode_idが1のノード(Postgres)がdownした場合でも、node_idが1のノード(Postgres)に検索クエリを投げるセッションが検索クエリを投げない限り、node_idが1のノードのstatusがupのままになることです。

試してみます。
node_idが1のPostgresを落とします。
[root@postgresql11-testserver-2 ap2]# systemctl stop postgresql-11.service
node_idが1のPostgresを落とした状態で、node_idが0のノードのload_balance_nodeのstatusがUPとなっているセッションで、SHOW POOL_NODESを実行した結果は以下のとおりです。
ap2=# SHOW POOL_NODES ;
 node_id |    hostname    | port | status | lb_weight |  role   | select_cnt | load_balance_node | replication_delay | last_
status_change
---------+----------------+------+--------+-----------+---------+------------+-------------------+-------------------+------
---------------
 0       | localhost      | 5433 | up     | 0.500000  | primary | 0          | true              | 0                 | 2018-
12-29 23:53:02
 1       | 192.168.86.135 | 5433 | up     | 0.500000  | standby | 0          | false             | 0                 | 2018-
12-30 00:01:57
(2 rows)
さらにデータをINSERTしてからSHOW POOL_NODESを実行してもnode_idが1のノードのstatusがupのままです。
ap2=# INSERT INTO sample (a) VALUES (9) ;
INSERT 0 1
ap2=# SHOW POOL_NODES ;
 node_id |    hostname    | port | status | lb_weight |  role   | select_cnt | load_balance_node | replication_delay | last_
status_change
---------+----------------+------+--------+-----------+---------+------------+-------------------+-------------------+------
---------------
 0       | localhost      | 5433 | up     | 0.500000  | primary | 0          | true              | 0                 | 2018-
12-29 23:53:02
 1       | 192.168.86.135 | 5433 | up     | 0.500000  | standby | 0          | false             | 0                 | 2018-
12-30 00:01:57
(2 rows)

SHOW POOL_NODESを実行する際は、node_1のノードの最新の状態を取得してからstatusを表示するようにするといいのになと思いました。

Pgpool-IIのSHOW POOL_NODESのload_balance_nodeについては以下のドキュメントが参考になります。

pgpoolのSHOW POOL_NODESでroleが両方ともstandbyになってしまう

ap2=# SHOW POOL_NODES ;
 node_id |    hostname    | port | status | lb_weight |  role   | select_cnt | load_balance_node | replication_delay | last_
status_change
---------+----------------+------+--------+-----------+---------+------------+-------------------+-------------------+------
---------------
 0       | localhost      | 5433 | up     | 0.500000  | standby | 3          | true              | 0                 | 2018-
12-16 22:53:53
 1       | 192.168.86.135 | 5433 | up     | 0.500000  | standby | 4          | false             | 0                 | 2018-
12-16 22:53:53
(2 rows)
pgpoolはpostgresqlサーバーがprimaryなのかstandbyなのかをSELECT pg_is_in_recovery()の結果で判断しています。 SELECT pg_is_in_recovery()を実行するユーザーとそのユーザーのパスワードとデータベースは、pgpool.confで指定します。 ユーザー名は「sr_check_user」、パスワードは「sr_check_password」、データベースは「sr_check_database」で指定します。 pgpool.confのデフォルト設定は以下のとおりです。
sr_check_user = 'nobody
sr_check_password = ''
sr_check_database = 'postgres'
この設定の場合、nobodyでパスワードなしでデータベースpostgresにアクセスできないと、SELECT pg_is_in_recovery()が実行できません。
実行できるように、pgpool.confだったり、pg_hda.confだったり、データベースpostgresqlにユーザーnobodyを追加したりします。

実行できるようにすると、以下のように正しくroleが表示されます。

ap2=# SHOW POOL_NODES ;
 node_id |    hostname    | port | status | lb_weight |  role   | select_cnt | load_balance_node | replication_delay | last_
status_change
---------+----------------+------+--------+-----------+---------+------------+-------------------+-------------------+------
---------------
 0       | localhost      | 5433 | up     | 0.500000  | primary | 0          | true              | 0                 | 2018-
12-16 23:12:16
 1       | 192.168.86.135 | 5433 | up     | 0.500000  | standby | 0          | false             | 0                 | 2018-
12-16 23:12:16
(2 rows)
参考 : FAQ - pgpool Wiki

unable to read data from frontend

ErogameScapeではpgpoolを使って冗長構成をとっています。
2つのサーバーマシンのそれぞれにApache、pgpool、PostgreSQLを動かしています。

構成

通常は192.168.0.14に接続するようにしています。
pgpoolを使い始めたころから原因不明で、192.168.0.13がちょいちょい切り離される事象が発生していました。
192.168.0.013のPostgreSQLは問題なく動いていて、keepalivedも切れていないので、pgpoolの問題だと思っていたのですが、切り離された場合のログを見ても、いきなり切れたようにしか見えませんでした。
pgpoolのVerがあがって、PostgreSQLからの応答がない…と判断するまでの時間をかえることができるようになったので、そのパラメータを十分大きくしてみたのですが、NGでした。

切り離される際のpgpoolのログは以下の通りです。

2016-12-27 03:31:33: pid 28889: LOG:  received degenerate backend request for node_id: 1 from pid [28889]
2016-12-27 03:31:33: pid 28889: WARNING:  write on backend 1 failed with error :"Success"
2016-12-27 03:31:33: pid 28889: DETAIL:  while trying to write data from offset: 0 wlen: 5
2016-12-27 03:31:33: pid 13031: LOG:  starting degeneration. shutdown host erogamescape13(5432)
2016-12-27 03:31:33: pid 19938: ERROR:  unable to read data from frontend
2016-12-27 03:31:33: pid 19938: DETAIL:  socket read failed with an error "Connection reset by peer"
2016-12-27 03:31:33: pid 30138: ERROR:  unable to read data from frontend
2016-12-27 03:31:33: pid 30138: DETAIL:  EOF encountered with frontend
2016-12-27 03:31:34: pid 13031: LOG:  Restart all children
2016-12-27 03:31:34: pid 16765: LOG:  child process received shutdown request signal 3
2016-12-27 03:31:34: pid 18712: LOG:  child process received shutdown request signal 3
2016-12-27 03:31:34: pid 18047: LOG:  child process received shutdown request signal 3
2016-12-27 03:31:34: pid 19036: LOG:  child process received shutdown request signal 3
2016-12-27 03:31:34: pid 13031: LOG:  failover: set new primary node: -1
2016-12-27 03:31:34: pid 13031: LOG:  failover: set new master node: 0
たいていこの時間あたりに切り離されるので、朝起きた時に気がついて、復帰させるということをしていました。
この3時30分頃、何が起こっているのか?と思って調べたところ、ログのローテーションの時間なことが分かりました。
そのログの中でもapacheのログのローテートの時間であることも分かりました。
ErogameScapeのApacheのログは1日で350MBくらいなのですが、このログを切り替えてapacheを再起動する際に、pgpoolが他のサーバーマシンで動いているPostgreSQLを切り離すようでした。
※単純にapacheを再起動するだけでは切り離されることはありませんでした。

そこで、Apacheのログが350MBの1/3くらいになるような時間にApacheのログをローテーションすることにしました。
それから2週間…pgpoolが他のサーバーマシンで動いているPostgreSQLを切り離すことはなくなりました…

なぜpgpoolがApacheの350MB程度のログをローテーションする際に、gpoolが他のサーバーマシンで動いているPostgreSQLを作成させて切り離すことがあるのか分からないのが、もやっとしますが、とりあえず切り離されなくなってよかったかなと…





could not access file "$libdir/pgpool-recovery": No such file or directory

pgpoolでオンラインリカバリを使用するにはpgpool_recovery のインストールが必要です。
インストールの際に下記のエラーが出来ました。

$ psql -p 5434 -f pgpool-recovery.sql template1
psql:pgpool-recovery.sql:4: ERROR:  could not access file "$libdir/pgpool-recovery": No such file or directory
psql:pgpool-recovery.sql:9: ERROR:  could not access file "$libdir/pgpool-recovery": No such file or directory
psql:pgpool-recovery.sql:14: ERROR:  could not access file "$libdir/pgpool-recovery": No such file or directory
psql:pgpool-recovery.sql:19: ERROR:  could not access file "$libdir/pgpool-recovery": No such file or directory

[環境]
CentOS6
PostgreSQL9.6.1のRPMをインストール済み
PostgreSQL9.3.15のRPMが稼働中
pgpool3.5.4

[対処]
# cp pgpool-recovery.so /usr/pgsql-9.6/lib/

$libdirである/usr/pgsql-9.6/lib/にpgpool-recovery.soをmake installした際に生成されるpgpool-recovery.soをコピー
$libdirはpg_config --pkglibdirで確認

※今までここでつまづいたことはなかったので、何か私が間違えている気がするのですが、原因が分かりませんでした…

pgpool経由で違うスキーマで同じテーブル名を定義している場合にINSERTが失敗する

pgpool経由で違うスキーマで同じテーブル名を定義している場合にSQLが失敗する場合、pgpool_regclass のインストールを忘れているだけ…だったらいいのですが、pgpoolを3.3.1から3.5.1にあげた際に、INSERTが出来なくなりました。

結論から書くと、再度、pgpool_regclass のインストールの手順を踏んだらインストールできるようになりました。


ErogameScapeのDBにはpublic.arrangementテーブルと、bookstore.arrangementテーブルがあります。
それぞれ定義は以下のとおりです。

ap2=# \d arrangement
                   テーブル "public.arrangement"
     列     |             型              |         修飾語
------------+-----------------------------+------------------------
 music      | integer                     | not null
 creater    | integer                     | not null
 created_at | timestamp without time zone | not null default now()
 updated_at | timestamp without time zone | not null default now()

ap2=# \d bookstore.arrangement
                                      テーブル "bookstore.arrangement"
    列    |             型              |                               修飾語
----------+-----------------------------+--------------------------------------------------------------------
 id       | integer                     | not null default nextval('bookstore.arrangement_id_seq'::regclass)
 users_id | integer                     | not null
 group_id | integer                     | not null
 shelf_id | integer                     | not null
 x        | integer                     | not null
 volumes  | integer                     | not null
 asin     | text                        | not null
 z        | integer                     | not null
 created  | timestamp without time zone | not null default now()
 modified | timestamp without time zone | not null default now()

これに以下のSQL発行すると失敗しました。
ap2=#  INSERT INTO public.arrangement ( music , creater ) VALUES ( '6419' , '1' ) ;
ERROR:  column "created" of relation "arrangement" does not exist
ap2=#  INSERT INTO arrangement ( music , creater ) VALUES ( '6419' , '1' ) ;
ERROR:  column "created" of relation "arrangement" does not exist
※pgpool_regclassをインストールしても、理由は調べていないのですがスキーマを指定しないとINSERTが失敗する…publicスキーマのarrangementテーブルにINSERTして欲しいのに、bookstoreスキーマのarrangementテーブルにINSERTしようとするので、明示的にpublicスキーマを指定していました。しかし、3.5.1にあげたら、publicスキーマを指定してもNGでした。

PostgreSQLのログは以下の通りです。

< 2016-04-28 20:30:51.281 JST > user=ap2 p=486 ERROR:  column "created" of relation "arrangement" does not exist at character 84
< 2016-04-28 20:30:51.281 JST > user=ap2 p=486 STATEMENT:  INSERT INTO "public"."arrangement"("music", "creater", "created_at", "updated_at", "created", "modified") VALUES ('6419','1','2016-04-28 20:30:51.268123+09','2016-04-28 20:30:51.268123+09','2016-04-28 20:30:51.268123+09','2016-04-28 20:30:51.268123+09')
< 2016-04-28 20:32:15.773 JST > user=ap2 p=706 ERROR:  column "created" of relation "arrangement" does not exist at character 84
< 2016-04-28 20:32:15.773 JST > user=ap2 p=706 STATEMENT:  INSERT INTO "public"."arrangement"("music", "creater", "created_at", "updated_at", "created", "modified") VALUES ('6419','1','2016-04-28 20:32:15.76399+09','2016-04-28 20:32:15.76399+09','2016-04-28 20:32:15.76399+09','2016-04-28 20:32:15.76399+09')

pgpool_regclass関数は3.3.1のときにインストールしているので存在します。
ap2=# select * FROM pg_available_extensions WHERE name = 'pgpool_regclass';
      name       | default_version | installed_version |         comment
-----------------+-----------------+-------------------+--------------------------
 pgpool_regclass | 1.0             |                   | replacement for regclass
(1 行)
再度、
$ psql -f pgpool-regclass.sql ap2
して、pgpool_regclassを置き換えたら動くようになりました。

記事検索