我之前也遇到过几乎一模一样的问题，当时折腾了好一阵才搞明白，给你几个排查和解决的思路：

1. 你可能用错了终止连接的核心函数！ #

你写的是pg_cancel_backend(pid, 10000)，但这个函数的作用只是取消当前正在运行的查询，根本不是终止整个连接会话！真正用来彻底切断连接的是pg_terminate_backend(pid)，而且它只需要pid这一个参数，不需要额外的超时参数。这大概率是你现在问题的核心——你以为在杀连接，其实只是取消了查询，会话根本没断。

正确的终止目标数据库空闲连接的SQL应该是：

SELECT pg_terminate_backend(pid) FROM pg_stat_activity 
WHERE datname = 'chat_app' 
  AND state = 'idle' 
  AND pid != pg_backend_pid(); -- 排除你当前的psql会话，避免把自己踢出去

这里额外加了datname = 'chat_app'精准定位到你的数据库，加pid != pg_backend_pid()是防止误杀自己当前的psql连接。

2. 检查连接是不是被应用自动重建了 #

如果你的ChatApp应用、Ecto连接池（比如DBConnection、Poolboy）或者任何相关的后台进程还在运行，你刚杀完空闲连接，连接池会立刻新建连接补上，导致你刚杀完10个，马上又冒出来10个新的空闲连接。这种情况的解决步骤是：

• 先完全关闭所有和ChatApp相关的进程：包括正在运行的应用服务、测试进程、iex控制台，甚至是后台挂着的编辑器插件（如果有连接数据库的话）
• 确认所有应用进程都停了之后，再执行上面的终止SQL，然后立刻跑mix ecto.reset

3. 不要只过滤idle状态的连接 #

有时候有些连接的状态可能是idle in transaction或者idle in transaction (aborted)，这些状态的连接用state = 'idle'是过滤不到的，但同样会占用数据库连接，导致你无法删除数据库。你可以先跑这个SQL查看目标数据库的所有连接详情：

SELECT pid, datname, state, query_start FROM pg_stat_activity WHERE datname = 'chat_app';

然后直接终止所有非当前会话的连接，不用管状态：

SELECT pg_terminate_backend(pid) FROM pg_stat_activity 
WHERE datname = 'chat_app' 
  AND pid != pg_backend_pid();

4. 极端情况：先禁止新连接再终止现有连接 #

如果上面的方法都不管用，你可以试试先把目标数据库设置成不允许新连接，再终止所有现有连接，这样就能彻底切断所有外部连接：

ALTER DATABASE chat_app WITH CONNECTION LIMIT 0; -- 禁止新连接进入
SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'chat_app' AND pid != pg_backend_pid();

完成数据库重置后，记得把连接限制改回默认（无限制）：

ALTER DATABASE chat_app WITH CONNECTION LIMIT -1;

我当时就是犯了用pg_cancel_backend代替pg_terminate_backend的低级错误，改完函数之后再配合关闭应用进程，问题立刻就解决了，你可以先试试第一个思路！