1，複製模式可靠性低
最早時候使用的是複製模式，數據到pgpool然後pgpool分別寫入n個postgres.發現經常出現數據不一致問題，導致最終只有一個數據庫可用
2，online recovery
基於PIRT的online recovery 配置複雜
3，基於流複製的主備模式
這個用到postgres9的新特性，前期配置測試都很easy，failover 也很好用，但是當服務連接上pgpool時，事務往往報錯 postgres error : failed to read kind from backend，這個我在之前的文章中提到過，至今無法解決。
4，連接數的困擾
num_init_children 原來理解成了一個池的大小，如果超過了會自動擴增，但是實際上往往不夠用，確切的說該值也是 pgpool-II 支持的從客戶端發起的最大併發連接數。
所以這個值配的儘量大些，並且對這個值的更改必須重啓pgpool.
5,client_idle_limit不要配置
當一個客戶端在執行最後一條查詢後如果空閒到了 client_idle_limit 秒數， 到這個客戶端的連接將被斷開.連接不應該讓pgpool來斷開，應該是應用主動去斷開。如果讓pgpool去斷開，會導致客戶端不可用。
當然pgpool也有一個好處，能夠快速找到連接的應用。因爲每個連接都是單獨的進程，所以啓動後會有num_init_children 個進程可以接受連接
使用# ps -ef |grep pgpool 可以看到
pgpool: wait for connection request 的進程是空進程，等待連接。
pgpool: postgres dbtest 10.115.53.167(51883) idle 這些進程是使用中的進程，並且可以看到是來自哪臺機器，什麼用戶，連接的是什麼數據庫。
當然使用select * from pg_stat_activity 也能查到 連接情況