Npgsql连接池与PostgreSQL会话关系及配置泄漏问题咨询

核心问题答复 #

• 关于NpgsqlConnection.Open和新建PostgreSQL会话的等价性
  只有在关闭连接池（连接字符串配置Pooling=false）的场景下二者完全等价：此时调用Open()会完整走TCP建连、PostgreSQL协议握手、身份认证、全新会话初始化的全流程，调用Dispose()/Close()时会直接终止对应PostgreSQL后端进程，会话永久销毁。
• 关于连接池启用场景下的等价性
  结论完全不成立。
  Npgsql连接池默认开启，核心逻辑是预先维护一组已完成建连的物理连接缓存。调用Open()时，池优先分配已存在的空闲物理连接，不会触发新会话创建；仅当池内无空闲连接、且当前池连接数未达上限时，才会新建物理连接也就是新的PostgreSQL会话。调用Dispose()/Close()时，物理连接不会被关闭，而是直接放回池内等待复用，对应的PostgreSQL会话会持续存活。
• 关于会话级配置的泄漏风险
  确实存在明确的跨租户泄漏风险，也是基于会话参数实现RLS多租户最容易踩的坑。
  通过set_config(..., false)设置的会话级GUC参数，生命周期和PostgreSQL会话完全绑定。连接被放回池时，默认配置下Npgsql不会主动清空这类参数，下一个业务逻辑复用该连接时，读到的就是上一个使用者设置的参数值，直接触发RLS越权。
  除了自定义GUC参数，临时表、会话级advisory lock、自定义预编译语句、会话级角色切换等所有绑定会话状态的操作，都存在同类泄漏风险。

RLS多租户场景的规避方案 #

不要依赖Npgsql连接池的默认清理逻辑，直接从流程上堵死泄漏可能：

• 每次调用Open()拿到连接后，第一时间显式执行当前租户ID的赋值，不要留任何空窗期——不管连接是新建还是复用的，都强制覆盖参数值，从根源上消除旧值的影响。
• 优先使用事务级参数替代会话级参数：调用set_config('app.tenant_id', 你的租户ID, true)，第三个参数is_local设为true时，参数仅在当前事务生命周期内生效，事务提交/回滚后会自动清空，就算连接被复用也不会残留旧值。
• 如果追求极致安全，可以在连接字符串配置Reset On Open=true，此时Npgsql每次从池取出连接时都会先执行会话重置，清空所有会话状态，但该操作会带来10%~20%的性能损耗，高并发场景需要提前评估。

注意：不要为了隔离租户给每个租户建独立连接池，租户量级上来后连接数会直接打爆PostgreSQL的最大连接限制，完全不具备可扩展性。

内容的提问来源于stack exchange，提问作者Barguast