写这篇文章，是想好心地给打算使用Pgpool的人提个醒：
Pgpool 真的不适合在企业范围使用。
我的主要理由是：
设计陈旧：
一旦后台任何节点Down掉，都会引发failover，它会杀掉所有子进程，再重新创建子进程，在此过程中，所有事务不分青红皂白都被停止，实际上相当于被rollback。这一点引起很多次的很多客户的质疑。也许这是不得已而为之，因为它没有transaction manager。
代码混乱:
因为项目的原因，多次深入到Pgpool-II的源代码中进行调查，发现代码写的很随意，注释很随意，而对是否输出日志，输出哪种类型的日志，到底是 DEBUG，还是INFO，或者ERROR，非常的没有规律，完全看开发者的心情。
文档混乱:
其官方文档的说明，质量非常低劣。各个版本的信息集合在一起，只有一个页面。和PostgreSQL的文档组织结构相比一个在地上一个在天上。Pgpool-II有几种运行模式，如stream replication，如master/slave，然而master/slave模式的说明也就是二三十行的样子。
由于代码管理上的懈怠和文档的混乱，其文档内容和代码无法严格匹配，很多时候都有误导性的信息，例如helthcheck的设定就是如此。又由于代码管理混乱，导致旧的配置参数在新的版本里被忽视，作用受到不应有的限制，最后整个参数的性质完全扭曲。
责任心不强：
具体就不点名了，此软件的最初开发者的能力，我本人还是十分佩服的；根据公开的信息显示，此人后来担任了某公司的领导职务，在网上搜pgpool，常常可以看到其公司署名的宣传pgpool的文档。结合上述两点，我在想，他们也许利润压力很大吧。但是产品改进如果不能作好，实际上是走不远的。
未经大规模商业考验:
作为采用C语言开发的系统软件，我认为在正式发布前，至少也应该进行静态与动态检查，防止出现大规模的内存泄漏吧。然而它确实就发生了，我用网上流行的内存泄露静态检查工具都可以发现的问题，他们居然没有尽早发现，后来出现了运行一两个小时就内存泄漏1个GB的严重问题。
所以说，目前为止Pgpool还是个玩具而已。如果需要类似的功能，类似的软件多着呢，犯不着一棵树上吊死。