pgxpool多租户场景下BeforeAcquire/AfterRelease执行顺序异常问题

1. 每次请求创建连接池是核心反模式 #

pgx连接池的设计初衷是全局复用连接，你在每个go-chi请求中新建连接池的操作完全违背了池化的目的：

• 连接无法复用，每次请求都要新建、销毁数据库连接，反而大幅降低性能
• 每个请求的连接池生命周期极短，请求结束后池会被销毁，其管理的连接会被立即释放，触发AfterRelease回调——这直接导致member_id刚设置就被清除，因为连接用完就被回收销毁。

正确的做法是：全局初始化一个pgx连接池，所有请求从这个全局池中获取、释放连接。

2. 连接生命周期与回调时机的误解 #

如果你的代码使用了pgxpool的自动连接管理方法（如Query/Exec），其内部执行流程是固定的：

1. 从池获取连接 → 触发BeforeAcquire设置member_id
2. 执行目标SQL查询（此时member_id处于有效状态，RLS规则可以正常生效）
3. 释放连接回池 → 触发AfterRelease清除member_id
4. 将查询结果返回给业务代码，业务代码输出结果

所以日志顺序会呈现为：设置member_id → 清除member_id → 输出查询结果，这是正常的执行顺序——看起来清除操作早于结果输出，但实际上查询执行时member_id是存在的，RLS逻辑不受影响。

如果你的RLS规则确实没有生效，那要检查是否在BeforeAcquire中错误地使用了全局SET而非SET LOCAL（SET LOCAL才会让变量仅对当前连接生效，符合多租户RLS的需求）。

3. 手动管理连接时的提前释放错误 #

如果是手动调用Acquire获取连接，却在查询完成前就调用了Release，会导致：

• 连接被提前放回池，触发AfterRelease清除member_id
• 后续查询执行时，连接的member_id已经被清除，RLS规则失效，同时日志显示清除操作早于结果输出

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