ErogameScapeのPostgreSQLを9.6から11にあげる時に発生した事象です。
再現試験をしていないのでメモです。

実行しないと、ErogameScapeでは、クエリの応答がとても遅くなります。
※データが少ない環境では、ANALYZEしなくても分からないと思います。

192.168.0.13(erogamescape13)がプライマリ
192.168.0.14がスタンバイ(同期レプリケーション)
という構成で、192.168.0.13でVACUUM ANALYZEコマンドを実行したら、いくら待っても応答が返ってこない事象が発生しました。
ap2=# VACUUM ANALYZE ;

[ap2@erogamescape13 ~]$ ps ax | grep VA
14098 pts/3    S+     0:00 grep VA
30871 ?        Ss     0:43 postgres: ap2 ap2 [local] VACUUM waiting for 3/2E61F968
何か待っています。
テスト環境でPostgreSQLを動かしているので、誰もデータの更新等はしていません。
統計情報を更新しているのでPostgreSQL内部ではデータが更新されていると思います。
全然応答が返らないのでCtrl-Cしてみました。
ap2=# VACUUM ANALYZE ;

^CCancel request sent
WARNING:  canceling wait for synchronous replication due to user request
DETAIL:  The transaction has already committed locally, but might not have been replicated to the standby.
ローカルではcommitしたけどstandbyではcommitしていないとのことでしたので…スタンバイを再起動すれば、WALの再生が始まるかな?と思い、スタンバイのpostgresqlを落としました。
このときの、pgpoolのSHOW POOL_NODESの結果は以下のとおりです。
[ap2@erogamescape14 ~]$ psql -p 8999 -h 192.168.0.101 -U postgres -c "SHOW POOL_NODES ;"
 node_id |   hostname   | port | status | lb_weight |  role   | select_cnt | load_balance_node | replication_delay | last_st
atus_change
---------+--------------+------+--------+-----------+---------+------------+-------------------+-------------------+--------
-------------
 0       | 192.168.0.14 | 5433 | down   | 0.500000  | standby | 242        | false             | 2073065311        | 2019-05
-05 12:54:04
 1       | 192.168.0.13 | 5433 | up     | 0.500000  | primary | 105        | true              | 0                 | 2019-05
-05 11:59:39
replication_delayの値が大変なことに…
スタンバイのpostgresqlを立ち上げたのですが、レプリケーション状態になりませんでした。
ログを確認すると以下のとおりWALがすでにないということでした。
[root@erogamescape14 ap2]# tail /var/lib/pgsql/11/data/log/postgresql-Sun.log
2019-05-05 13:04:31.122 JST [29843] LOG:  started streaming WAL from primary at 2/B2000000 on timeline 1
2019-05-05 13:04:31.122 JST [29843] FATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 0000000100000002000000B2 has already been removed
アーカイブはとっていないので、レプリケーション状態にもっていくにはpg_basebackupをしないと駄目になりました。
VACUUM ANALYZしただけで、そんなにWALを生成するのか?と、確認したところ
[root@erogamescape13 pg_wal]# ls -lh
合計 1009M
-rw------- 1 postgres postgres  16M  5月  5 13:04 2019 0000000100000003000000BE
-rw------- 1 postgres postgres  16M  5月  5 12:57 2019 0000000100000003000000BF
-rw------- 1 postgres postgres  16M  5月  5 12:58 2019 0000000100000003000000C0
-rw------- 1 postgres postgres  16M  5月  5 12:58 2019 0000000100000003000000C1
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000C2
-rw------- 1 postgres postgres  16M  5月  5 12:58 2019 0000000100000003000000C3
-rw------- 1 postgres postgres  16M  5月  5 12:58 2019 0000000100000003000000C4
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000C5
-rw------- 1 postgres postgres  16M  5月  5 12:58 2019 0000000100000003000000C6
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000C7
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000C8
-rw------- 1 postgres postgres  16M  5月  5 12:58 2019 0000000100000003000000C9
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000CA
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000CB
-rw------- 1 postgres postgres  16M  5月  5 12:58 2019 0000000100000003000000CC
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000CD
-rw------- 1 postgres postgres  16M  5月  5 12:58 2019 0000000100000003000000CE
-rw------- 1 postgres postgres  16M  5月  5 12:58 2019 0000000100000003000000CF
-rw------- 1 postgres postgres  16M  5月  5 12:58 2019 0000000100000003000000D0
-rw------- 1 postgres postgres  16M  5月  5 12:58 2019 0000000100000003000000D1
-rw------- 1 postgres postgres  16M  5月  5 12:58 2019 0000000100000003000000D2
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000D3
-rw------- 1 postgres postgres  16M  5月  5 13:00 2019 0000000100000003000000D4
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000D5
-rw------- 1 postgres postgres  16M  5月  5 13:00 2019 0000000100000003000000D6
-rw------- 1 postgres postgres  16M  5月  5 13:01 2019 0000000100000003000000D7
-rw------- 1 postgres postgres  16M  5月  5 13:01 2019 0000000100000003000000D8
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000D9
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000DA
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000DB
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000DC
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000DD
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000DE
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000DF
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000E0
-rw------- 1 postgres postgres  16M  5月  5 13:03 2019 0000000100000003000000E1
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000E2
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000E3
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000E4
-rw------- 1 postgres postgres  16M  5月  5 13:03 2019 0000000100000003000000E5
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000E6
-rw------- 1 postgres postgres  16M  5月  5 13:03 2019 0000000100000003000000E7
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000E8
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000E9
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000EA
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000EB
-rw------- 1 postgres postgres  16M  5月  5 13:00 2019 0000000100000003000000EC
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000ED
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000EE
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000EF
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000F0
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000F1
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000F2
-rw------- 1 postgres postgres  16M  5月  5 13:03 2019 0000000100000003000000F3
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000F4
-rw------- 1 postgres postgres  16M  5月  5 13:00 2019 0000000100000003000000F5
-rw------- 1 postgres postgres  16M  5月  5 13:03 2019 0000000100000003000000F6
-rw------- 1 postgres postgres  16M  5月  5 13:03 2019 0000000100000003000000F7
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000F8
-rw------- 1 postgres postgres  16M  5月  5 13:01 2019 0000000100000003000000F9
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000FA
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000FB
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000FC
と1GBを超えるWALを短時間に生成していました。

ErogameScapeを9.6から11に移行する際は、リストア→ANALYZE→レプリケーションの順番に実行することにしました。