今天遇到一个问题，就是pg一直报错，说有太多的客户端连接到数据库上面。但现在不知道是什么程序连接。pg默认的max_connection是100，我并没有修改过，以为平时公司内部用，应该够了，但现在貌似这100个连接都被消耗掉。在网上google了一下，发现用下面的SQL，居然可以查看所有连接的状况：
select * from pg_stat_activity;
结果集会显示出当前连接的数据库名，用户，IP地址，连接开始时间，查询的语句等。
这里的pg_stat_activity其实是一个视图，它的定义可以在postgres这个数据库里面的视图部分找到，以下是它的定义：
CREATE OR REPLACE VIEW pg_stat_activity AS SELECT s.datid, d.datname, s.procpid, s.usesysid, u.rolname AS usename, s.application_name, s.client_addr, s.client_hostname, s.client_port, s.backend_start, s.xact_start, s.query_start, s.waiting, s.current_query FROM pg_database d, pg_stat_get_activity(NULL::integer) s(datid, procpid, usesysid, application_name, current_query, waiting, xact_start, query_start, backend_start, client_addr, client_hostname, client_port), pg_authid u WHERE s.datid = d.oid AND s.usesysid = u.oid;
可以看到，pg_stat_activity这个视图是由 pg_database，pg_authid，以及两个方法的结果来组合成的。
pg_database ，顾名思义就是储存了在pg里面的所有的数据库名称。
pg_authid，是用来储存pg的登录账号。
pg_stat_get_backend_activity在Postgresql里面的定义如下：
CREATE OR REPLACE FUNCTION pg_stat_get_backend_activity(integer) RETURNS text AS 'pg_stat_get_backend_activity' LANGUAGE internal STABLE STRICT COST 1;
ALTER FUNCTION pg_stat_get_backend_activity(integer) OWNER TO postgres; COMMENT ON FUNCTION pg_stat_get_backend_activity(integer) IS 'statistics: current query of backend';
可见它是一个pg的内部方法，用来统计当前query的数目。
看来pg的内部结构还是挺清楚简单的。越来越喜欢pg的这种简单与强大了！
好了，现在我们找出所有连接到数据库的进程了，那么如何去杀死那些IDEL的进程从而释放出连接呢？
如果pg的版本是 8.4及以上的，可以很简单地用下面的语句来杀死所有IDEL进程 ：
SELECT pg_terminate_backend(procpid) FROM pg_stat_activity WHERE current_query='<IDLE>'
pg_terminate_backend 是pg的内部方法，另外还有一个叫pg_cancel_backend，这个方法在8.4以前的版本中就一直存在。这两个方法的区别在于，pg_cancel_backend 只是取消当前某一个进程的查询操作，但不能释放数据库连接。但pg_terminate_backend 可以在pg的后台杀死这个进程，从而释放出宝贵的连接资源。
但如果pg的版本是在8.3或者以下的，就不能用上面的方法了。首先，同样的，要先找出pg里面有什么IDEL的连接，然后在windows的command里面，输入以下命令：
pg_ctl kill TERM PID
以上命令是调用pg的后台命令行 pg_ctl去执行命令，直接kill那个进程。这样会同时导致windows和pg的进程同时被杀死，从而释放资源。比较麻烦的是，只能手动地一个一个进程来杀，没有批量的方法。
另外一个比较有用的工具是pgAdmin提供的，在pgAdmin -> 工具 -> 服务器状态，会列出当前pg里面所有的连接，从而可以看到什么进程在进行什么操作，pid是多少，什么时候开始，运行多长时间了，结果是跟用 pg_stat_activity 查询出来的结果一样的。
